Добавление российских репозиториев Mandriva

[verg]

Да больше скажу: сайт http://urpmi.mandriva.ru/ неофициальный
Всё, кому теперь верить =)

вот не понимаю - какая религия запрещает СРАЗУ подключать MIB-KDE455 ВМЕСТЕ с другими репозиториями MIB?

Я ж писал выше как обновлял (обновлял, подключив всё сразу) Всё = всё, что на самом деле требуется.

Да, все беды только от отсутствия информации (про 2010.2 и так мало разговоров, так что всё в порядке)
Вон поговорили. Надеюсь конструктивно.

[Shurik]

Да больше скажу: сайт http://urpmi.mandriva.ru/ неофициальный
Всё, кому теперь верить =)

вот не понимаю - какая религия запрещает СРАЗУ подключать MIB-KDE455 ВМЕСТЕ с другими репозиториями MIB?

Я ж писал выше как обновлял (обновлял, подключив всё сразу)

Да, все беды только от отсутствия информации (про 2010.2 и так мало разговоров, так что всё в порядке)
Вон поговорили. Надеюсь конструктивно.

Мы говорим об одном и том-же?
С РЕКОМЕНДУМОГО сайта urpmi.mandriva.ru источник MIB-KDE455 подключается, или нет? Вот просто - "ДА", или "НЕТ"?

[verg]

Сделаем выводы, раз уж МИБ убежал быстрее паровоза:
То уговаривать автора сайта или удалить совсем МИб с сайта (не очень хорошая идея)
Или добавить кнопку на репы с кде 4.5.5 (здравая мысль) - Тем более, что даже в эду2010.2 эти репы есть (не на сайте urpmi.mandriva.ru)

Вроде это так обычно делается. =)

Мы говорим об одном и том-же?

Да, поддерживаю ваше искреннее негодование.

[Shurik]

Сделаем выводы, раз уж МИБ убежал быстрее паровоза:
То угаваривать автора сайта или удалить совсем МИб с сайта (не очень хорошая идея)
Или добавить кнопку на репы с кде 4.5.5 (здравая мысль) - Тем более, что даже в эду2010.2 эти репы есть (не на сайте urpmi.mandriva.ru)

Вообще-то я писал о другом - или добавить репы KDE в MIB, или убрать MIB из рекомендованных, т.е. перенести MIB на вкладку рядышком с "COOKER". С соответствующими пояснениями. Пояснения о том, что необходимо подключать EDU, что-бы НОРМАЛЬНО заработало обновление MIB - это, извиняюсь - ИДИОТИЗМ!

[verg]

Вы несколько не поняли, что я написал: (поясню)

Вообще-то я писал о другом

Я как раз об этом и написал в последнем посте про выводы.

Пояснения о том, что необходимо подключать EDU, что-бы НОРМАЛЬНО заработало обновление MIB - это, извиняюсь - ИДИОТИЗМ!

Уточню (просвещу) про какое именно ЭДУ речь: ftp://ftp.mandriva.ru/EduMandriva/educont...0.1/i586/kde45/ (тоже самое, что и в репах миб, но одной репой и без extra, и others - для сведения)
Эти кеды так же шли в образах Edumandriva2010.2

[Pulfer]

НО! Это ещё не всё! После того, как MIB подключен и запуска, как обычно
#urpmi --auto-update --auto-select --auto
Получаем на выхлопе нерабочую среду KDE. Т.е. после обновления с MIB KDE валится в хлам.

Эта проблема, скорее всего, возникла после недавнего обновления Qt4 с 4.7.3 до 4.7.4. Тестирование показало, что да, теперь надо обязательно и KDE4 обновлять. Так что будет перенос KDE из отдельного репозитория в /basic.

Плохо, конечно, что о несовместимости стало известно уже по отзывам пользователей. Но что случилось, то случилось.

В планах на ближайшее будущее, кстати, портировать в 2010.2 Qt4 4.8 и KDE4 4.8. Наверное, когда KDE4 4.8.1 выйдет. И если всё будет нормально собираться и работать.

[verg]

НО! Это ещё не всё! После того, как MIB подключен и запуска, как обычно
#urpmi --auto-update --auto-select --auto
Получаем на выхлопе нерабочую среду KDE. Т.е. после обновления с MIB KDE валится в хлам.

Эта проблема, скорее всего, возникла после недавнего обновления Qt4 с 4.7.3 до 4.7.4. Тестирование показало, что да, теперь надо обязательно и KDE4 обновлять. Так что будет перенос KDE из отдельного репозитория в /basic.

Плохо, конечно, что о несовместимости стало известно уже по отзывам пользователей. Но что случилось, то случилось.

В планах на ближайшее будущее, кстати, портировать в 2010.2 Qt4 4.8 и KDE4 4.8. Наверное, когда KDE4 4.8.1 выйдет. И если всё будет нормально собираться и работать.

На самом деле давно нужно было 4.5.5 перенести в базовые, хотя она мне понравилось как отдельная репа.

[Pulfer]

На самом деле давно нужно было 4.5.5 перенести в базовые, хотя она мне понравилось как отдельная репа.

Надо было, конечно, но достаточно продолжительное время какой-то из драйверов в комбинации с какими-то моделями видеокарт плохо работал с KDE4 4.5. Поэтому тогда решили сохранить возможность пользователям остаться на KDE4 4.4. Потом проблема с драйверами исчезла, но про KDE уже как-то забыли... Только сейчас снова тема поднялась.

[Shurik]

На самом деле давно нужно было 4.5.5 перенести в базовые, хотя она мне понравилось как отдельная репа.

Надо было, конечно, но достаточно продолжительное время какой-то из драйверов в комбинации с какими-то моделями видеокарт плохо работал с KDE4 4.5. Поэтому тогда решили сохранить возможность пользователям остаться на KDE4 4.4. Потом проблема с драйверами исчезла, но про KDE уже как-то забыли... Только сейчас снова тема поднялась.

Так она и поднялась именно потому, что старый KDE, после обновленя с базы, валиться начал. На мой взгляд просто необходимо KDE4.5.5 переносить в базу.

[Pulfer]

Так она и поднялась именно потому, что старый KDE, после обновленя с базы, валиться начал.

Ага.

На мой взгляд просто необходимо KDE4.5.5 переносить в базу.

Да, сейчас в списке рассылки MIB голосование идёт, перенести KDE 4.5.5 в /basic или вынести Qt4 4.7.4 в /KDE455. Пока что большинство за первый вариант. Надеюсь, уже сегодня вопрос решится и всё будет сделано.

[Shurik]

На самом деле давно нужно было 4.5.5 перенести в базовые, хотя она мне понравилось как отдельная репа.

А о чём мы тогда спорили?
Именно про это я и писал. И голосование на MIB нужно было устраивать ДО размещения пакетов валящих KDE, а не после. Просто нужно было думать и проверять. И вариантов всего три:
- Убрать MIB из "рекомедуемых обновлений" на отдельную вкладку рядом с кукером.
- Убрать из базы все пакеты под QT4 и KDE4.5.5
- Добавить QT4 и KDE4.5.5 в базу

[Shurik]

На самом деле давно нужно было 4.5.5 перенести в базовые, хотя она мне понравилось как отдельная репа.

Надо было, конечно, но достаточно продолжительное время какой-то из драйверов в комбинации с какими-то моделями видеокарт плохо работал с KDE4 4.5. Поэтому тогда решили сохранить возможность пользователям остаться на KDE4 4.4. Потом проблема с драйверами исчезла, но про KDE уже как-то забыли... Только сейчас снова тема поднялась.

Опять-же - недостаточное тестирование!!!
Лично у меня, после обновления с MIB возникла проблема работы драйвера NVidia на видеокарте 9600GT и сетевухи - Realtek GBE. Первым делом смотрим установленное оборудование, а затем - загруженные модули и прерывания:
# lspci
00:00.0 Host bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external gfx0 port B) (rev 02)
00:00.2 Generic system peripheral [0806]: ATI Technologies Inc Device 5a23
00:02.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port B)
00:04.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port D)
00:09.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (PCI express gpp port H)
00:0a.0 PCI bridge: ATI Technologies Inc RD890 PCI to PCI bridge (external gfx1 port A)
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA Controller [AHCI mode] (rev 40)
00:12.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:12.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:13.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:13.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 42)
00:14.1 IDE interface: ATI Technologies Inc SB700/SB800 IDE Controller (rev 40)
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia (Intel HDA) (rev 40)
00:14.3 ISA bridge: ATI Technologies Inc SB700/SB800 LPC host controller (rev 40)
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge (rev 40)
00:14.5 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI2 Controller
00:15.0 PCI bridge: ATI Technologies Inc Device 43a0
00:16.0 USB Controller: ATI Technologies Inc SB700/SB800 USB OHCI0 Controller
00:16.2 USB Controller: ATI Technologies Inc SB700/SB800 USB EHCI Controller
00:18.0 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] HyperTransport Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] DRAM Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Miscellaneous Control
00:18.4 Host bridge: Advanced Micro Devices [AMD] K10 [Opteron, Athlon64, Sempron] Link Control
01:00.0 VGA compatible controller: nVidia Corporation G94 [GeForce 9600 GT] (rev a1)
02:00.0 USB Controller: Device 1b6f:7023 (rev 01)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8169B PCI Express Gigabit Ethernet controller (rev 06)
04:00.0 USB Controller: Device 1b6f:7023 (rev 01)
05:06.0 Ethernet controller: Atheros Communications Inc. Atheros AR5001X+ Wireless Network Adapter (rev 01)
05:0e.0 FireWire (IEEE 1394): VIA Technologies, Inc. VT6306 Fire II IEEE 1394 OHCI Link Layer Controller (rev c0)
Нашли нужное - проводную сетевуху и видео. Проверяем:
#lsmod | grep nvidia
nvidia 11983421 40
i2c_core 30375 3 videodev,i2c_piix4,nvidia
и, поскольку у меня сетевуха Realtek
#lsmod | grep r81
r8169 157238 0

Проверяю загрузочную запись IRQ в ACPI:

# dmesg | grep nvidia
# dmesg | grep r8169
Смотрю на прерывания - IRQ - и у видео и у сетевухи - IRQ-18. Результат - и то и другое работает через ж.. Т.е., перевожу на русский - ни QT, ни KDE тут не при делах. Вообще. За это отвечает машинная запись ACPI ядра.
Как развести IRQ? Два варианта:
1. Пересобрать ядро с установкой r8169 в тело ядра, а не модулем
2. После загрузки в графике установить другой драйвер на сетевуху. (Именно - в графике, поскольку на видео IRQ выделятся ещё BIOS материнской платы, а сетевухе - "ядерный" ACPI. Так что гораздо проще переписать таблицу загрузки IRQ в ACPI, чем ковырять firmware bios в самом ядре. Проще говоря - если уж за видео "отжат" в BIOS IRQ-18, то он за ней и останется, а вот сетевухе, при загрузке нового модуля, ACPI придётся выделить и записать в таблицу загрузки новый, не занятый никаким оборудованием IRQ.)
Поскольку я чел ленивый - пересобирать ядро - лень. Лезу на сайт Realtek - http://www.realtek.com.tw Там нахожу драйвер для сетевухи Realtek GBE под Linux для ядер 2.6ххх Скачиваю, распаковываю, читаю README, устанавливаю. Проверяю:

#dmesg | grep nvidia
nvidia: module license 'NVIDIA' taints kernel.
nvidia 0000:01:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
nvidia 0000:01:00.0: setting latency timer to 64
#dmesg | grep r8168
r8168 Gigabit Ethernet driver 8.028.00-NAPI loaded
r8168 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
r8168 0000:03:00.0: setting latency timer to 64
r8168 0000:03:00.0: irq 43 for MSI/MSI-X
r8168: This product is covered by one or more of the following patents: US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776, and US6,327,625.
r8168 Copyright © 2011 Realtek NIC software team <nicfae@realtek.com>
r8168: eth0: link down
r8168: eth0: link up
r8168: eth0: link up

Угу. Сработало. ACPI записал в таблицу IRQ-17 для сетевухи и теперь будет разводить сетевуху и видео на разные IRQ ещё при загрузке ядра. Теперь нужно прописать загрузку модуля r8168 - ведь ядро о модуле r8168 не в курсах вообще. Лезем:

#mc -> /etc/modprobe.conf
alias eth0 r8169
install scsi_hostadapter /sbin/modprobe pata_atiixp; /sbin/modprobe ahci; /sbin/modprobe ata_piix; /bin/true
install usb-interface /sbin/modprobe ehci_hcd; /sbin/modprobe ohci_hcd; /bin/true
alias pci:v000010ECd00008168sv00001458sd0000E000bc02sc00i00 r8169

Угу. Так и есть - на eth0 и устройство pci:v000010ECd00008168sv00001458sd0000E000bc02sc00i00, то-есть сетевуху, подгружается модуль ядра - r8169. Исправляем:

alias eth0 r8168
install scsi_hostadapter /sbin/modprobe pata_atiixp; /sbin/modprobe ahci; /sbin/modprobe ata_piix; /bin/true
install usb-interface /sbin/modprobe ehci_hcd; /sbin/modprobe ohci_hcd; /bin/true
alias pci:v000010ECd00008168sv00001458sd0000E000bc02sc00i00 r8168
Сохраняем - F2
Перезагружаемся и проверяем:

# dmesg | grep nvidia
nvidia: module license 'NVIDIA' taints kernel.
nvidia 0000:01:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
nvidia 0000:01:00.0: setting latency timer to 64
# dmesg | grep r8168
r8168 Gigabit Ethernet driver 8.028.00-NAPI loaded
r8168 0000:03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
r8168 0000:03:00.0: setting latency timer to 64
r8168 0000:03:00.0: irq 43 for MSI/MSI-X
r8168: This product is covered by one or more of the following patents: US5,307,459, US5,434,872, US5,732,094, US6,570,884, US6,115,776, and US6,327,625.
r8168 Copyright © 2011 Realtek NIC software team <nicfae@realtek.com>
r8168: eth0: link down
r8168: eth0: link up
r8168: eth0: link up

Всё ОК!
И видюха и сетевуха заработали отменно - как и положено. И совершенно естественным образом стабильно заработали и QT и KDE.

[SinClaus]

Надо же, какие эмоции... Смотрим у меня на рабочей машине:

Код: Выделить всё

# lspci
...........
01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8500 GT] (rev a1)
..........
04:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
...........

Прекрасно работали и продолжают работать не смотря на обновления из MIB, restricted и прочая и прочая.

[Pulfer]

Лично у меня, после обновления с MIB возникла проблема работы драйвера NVidia на видеокарте 9600GT и сетевухи - Realtek GBE. ... И видюха и сетевуха заработали отменно - как и положено. И совершенно естественным образом стабильно заработали и QT и KDE.

Тогда вопрос. В каком именно установленном из MIB пакете проблема?

А вообще, де факто MIB сейчас - это 4 человека (даже 3.5, потому что я для MIB что-то собираю раз в месяц в среднем), ни один из которых уже не может уделять репозиториям столько же времени, сколько получалось раньше. Раньше тестированием занималось 2 человека, сейчас этим заниматься некому. И не факт, что проект вообще доживёт до выхода Мандривы 2012...

[Shurik]

Надо же, какие эмоции... Смотрим у меня на рабочей машине:

Код: Выделить всё

# lspci
...........
01:00.0 VGA compatible controller: nVidia Corporation G86 [GeForce 8500 GT] (rev a1)
..........
04:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
...........

Прекрасно работали и продолжают работать не смотря на обновления из MIB, restricted и прочая и прочая.

И что?
На разных материнских платах и разных чипсетах одно и то-же оборудование работает по-разному. И IRQ раскидывается по-разному. Так что это - не показатель. Показатель - вывод dmesg данного оборудования.

Лично у меня, после обновления с MIB возникла проблема работы драйвера NVidia на видеокарте 9600GT и сетевухи - Realtek GBE. ... И видюха и сетевуха заработали отменно - как и положено. И совершенно естественным образом стабильно заработали и QT и KDE.

Тогда вопрос. В каком именно установленном из MIB пакете проблема?

А вообще, де факто MIB сейчас - это 4 человека (даже 3.5, потому что я для MIB что-то собираю раз в месяц в среднем), ни один из которых уже не может уделять репозиториям столько же времени, сколько получалось раньше. Раньше тестированием занималось 2 человека, сейчас этим заниматься некому. И не факт, что проект вообще доживёт до выхода Мандривы 2012...

Ядро 2.6.38.8-desktop-69mib
Хотя, честно говря, я в этом не совсем уверен, т.к. именно перед обновлением ядра я перепрошил BIOS на 10b - BETA. BIOS легко и просто вносит изменения в распределение IRQ. Так что...
С одной стороны ACPI ядра должен, по идее, корректно распределять IRQ, а с другой стороны - хрен знает, что там разработчики по поводу IRQ в бете накрутили. Поэтому совершенно конкретно говорить, что виновато именно ядро - я-бы не стал, хотя - с другой стороны, не у меня одного возникли проблемы, т.е. вполне может быть и ядро виновато, точнее - его сборка.

[Shurik]

to Pulfer
Тут такое дело - ещё лет 7 назад уже был косяк на NForce чипсетах с распределением IRQ. Давались пара решений - о програмном изменениии (внесении таблицы) в модуль ACPI ядра и мой - с пересборкой ядра (модуль-тело ядра-сторонний драйвер) различных устройств. Как правило - косяки в 99% случаев были именно почему-то в связке видеокарта-сетевуха. Я писал - как их развести без знания програмирования на аппаратном уровне.
Дело в том, что таблица прерываний и алгоритм перенаправлений (роутинга) IRQ в ACPI открыто и доступно у Intel и VIA и полностью закрыто у NVidia и AMD.
Поэтому, чисто предположение, ...достаточно продолжительное время какой-то из драйверов в комбинации с какими-то моделями видеокарт плохо работал с KDE4 4.5... - это относится как раз к владельцам мат. плат на NForce и AMD. Т.е. косячил именно ACPI с IRQ. НО! Поскольку таких косяков за ACPI не наблюдалось уже порядочно - народ просто подзабыл, что такое, вообще-то - не из области научной фантастики, а вполне-таки реальное дело.

[Pulfer]

Ядро 2.6.38.8-desktop-69mib
Хотя, честно говря, я в этом не совсем уверен, т.к. именно перед обновлением ядра я перепрошил BIOS на 10b - BETA. BIOS легко и просто вносит изменения в распределение IRQ. Так что...

Ну да, тут и правда не факт, т.к. на это ядро вроде ещё никто не жаловался

[verg]

Ядро 2.6.38.8-desktop-69mib
Хотя, честно говря, я в этом не совсем уверен, т.к. именно перед обновлением ядра я перепрошил BIOS на 10b - BETA. BIOS легко и просто вносит изменения в распределение IRQ. Так что...

Ну да, тут и правда не факт, т.к. на это ядро вроде ещё никто не жаловался

Я жаловался http://mib.pianetalinux.org/mib/forum/view...?p=15483#p15483
Шучу. Там была локальная проблема определенного ноута. Ядро на самом деле нормальное.
А вообще /experts особая репа, не стоит её подключать бездумно.

[Shurik]

Я жаловался http://mib.pianetalinux.org/mib/forum/view...?p=15483#p15483
Шучу. Там была локальная проблема определенного ноута. Ядро на самом деле нормальное.
А вообще /experts особая репа, не стоит её подключать бездумно.

Ничего подобного.
Просто практически нигде и никто не пишет о работе ACPI. Могу пояснить вкратце:
ACPI разделены на 2 вида:
1. ACPI который в BIOS материнской платы
2. ACPI который либо в драйвере чипсета (Windows), либо в таблице прерываний модуля ACPI в ядре Linux
Производитель материнской платы изначально закладывает назначения прерываний в BIOS материнской платы. На каждой плате имеется подпункт - IRQ - auto, либо IRQ - manual, т.е. пользователь либо назначает прерывания самостоятельно, либо полагается на производителя материнской платы + драйвер (модуль) ACPI. НО! Тут имеется ограничение - дело в том, что в BIOS РЕАЛЬНЫЕ ПРЕРЫВАНИЯ. И их число ограничено 9. Из них уже зарезервировано под таймер, порты COM и LPT, клавиатуру и звуковую карту(бывает - да, бывает - нет) 5(4) реальных прерываний. Остальные 5 реальных прерываний рарезервировано под AGP и PCI-порты на материнской плате. Дело в том, что порт PCI-EXPRESS под современное видео, равно как и другие порты PCI-EX не имеют зарезервированных прерываний вообще. Для PCI-EX в BIOS "зашито" виртуальное прерывание. Как правило - от IRQ-12 до IRQ-18. Раньше в BIOS был пункт Assign IRQ for video, сейчас - его убрали и жестко "зашивают" виртуальный IRQ в BIOS. Имеет своё прерывание только PCI и AGP. Можно назначить любое реальное прерывание на любое оборудование, которое вставлено в порт PCI на материнской плате. Осчет (в BIOS) начинается от порта видеокарты. А как быть с другим оборудованием? А вот тут вступают в силу так называемые виртуальные прерывания - их BIOS материнской платы может устанавливать уже 22, включая 9 реальных. НО! Их как-то нужно перенаправлять - ведь незадействованных реальных-то всего 4-5. Вот тут-то и вступает в силу таблица прерываний и роутинга ACPI. Внешний ACPI (драйвер, или модуль) аппратных ограничений не имеет и может назначать прерывания вплоть 100. Если рассмотреть на моём примере выше, то видно, что в ACPI сетевухи прописан ещё один IRQ - r8168 0000:03:00.0: irq 43 for MSI/MSI-X Если сделать вывох gmesg | grep IRQ, то можно увидеть, что кроме сетевухи на IRQ-17 висит ещё и контроллер SATA-ACHI При работе ОДНОВРЕМЕННО и сетевухи (что-то качаю с и-нета) и харда (что-то копирую) происходит одновременное обращение к IRQ-17 и сетевухи и контроллера, НО! вспоминаем - контроллер жесто "зашит" ещё в BIOS материнской платы, на приоритетном уровне (BIOS-ACPI-route IRQ-6-7-8-9 -> IRQ-17). Поэтому когда идёт одновременное обращение, то уже начинает работать ВНЕШНЯЯ таблица роутинга ACPI. И согласно этой таблице, что-бы не было конфликта прерываний, сетевуха перенаправляется на внешний виртуальный IRQ-43 (BIOS-ACPI-route IRQ-6-7-8-9 -> IRQ-17 -> ACPI-route IRQ-17 -> IRQ-43). У контроллера происходит обращение - внутренний виртуальный IRQ - реальный IRQ, а сетевухи - внешний виртуальный IRQ - внутренний виртуальный IRQ - внутренний реальный IRQ. Т.е. сетевуха всегда будет работать медленнее, чем более приоритетный контроллер, но поскольку всё это происходит на бешенный частотах работы процессора и памяти (GHz), то пользователь этого не замечает совершенно. Всё это работает до определённог момента - а точнее до ноутбука-нетбука и пр. девайсов, которые НЕ ИМЕЮТ внешних портов PCI. Производители данный девайсов решили - коль уж внешних слотов нет, то и нехрена на них IRQ прописывать. И...понеслось... Каждый производитель попёр - кто и как может и как хочет. Т.е. начали впихивать внутренние виртуальные IRQ не согласно таблице, а ...как надумается... Именно поэтому на ноуты СВОИ драйвера и на видео и на чипсеты и на всё прочее.
Поэтому - рекомендация - при установке Linux на ноут отключать перед установкой "ядерный" (внешний ACPI. В 99% случаев - это гарантирует более-менее нормальную установку. Т.е. в загрузке ядра, перед установкой, ставить ACPI=OFF, т.е предоставлять перенапрвление (роутинг) IRQ BIOS-ACPI.

[verg]

Ничего подобного - что?
Зачем этот столб текста привязали к моему сообщению.

[Shurik]

Ничего подобного - что?
Зачем этот столб текста привязали к моему сообщению.

...Ничего подобного... - Это - не локальная проблема локального ноута - это общая проблема. Просто для ноута - в особенности. А почему именно для нота - постарался пояснить.
Прошу прощения за ...много букв...

[verg]

Решили всё таки не перемещать КДЕ4.5.5 в базовые репы, а просто пофиксить пакеты Qt4.7.4 (уже обновлены в репах) http://forum.mandriva.com/en/viewtopic.php?p=855513#p855513

[Pulfer]

Решили всё таки не перемещать КДЕ4.5.5 в базовые репы, а просто пофиксить пакеты Qt4.7.4 (уже обновлены в репах) http://forum.mandriva.com/en/viewtopic.php?p=855513#p855513

Скоро вообще Qt4 4.8 будет, наверное. Изначально были опасения, что KDE4 4.4.x из официальных репозиториев не будет нормально работать с Qt4 4.8, но вроде нормально работает. Хотя надо ещё потестировать будет, конечно.

Qt4 4.8 нам надо, чтобы перейти на KDE4 4.8. И хотя KDE4 будет лежать в отдельном репозитории, библиотеки общего назначения будут в /basic.

Примерный план по KDE4 4.8:
1. В самое ближайшее время будет доступен внутренний репозиторий с бэкпортами необходимых для сборки KDE4 библиотек. Тестировать будем в течение недели. Если проблем не возникнет, библиотеки уйдут в /basic. Там около 25 пакетов.
2. Потом для внутреннего тестирования будет создан репозиторий с KDE4 4.8.0. Будем тестировать. Сборка будет несколько отличаться от той, что в Кукере - Dolphin будет из апстрима и т.д. Не потому, что Dolphin Росы чем-то хуже. Просто он завязан на psyncclient, а его портировать мы пока не будем. Интеграции с network-manager тоже не будет.
3. После выхода KDE4 4.8.1 мы собираем обновлённые пакеты, тестируем и выкладываем в открытый репозиторий.
4. Потом собираем 4.8.2, 4.8.3 и т.д. по мере их выхода.

Под внутренним репозиторием я имею в виду не закрытый каталог, а просто репозиторий, из которого пользователяем что-либо ставить крайне не рекомендуется. Хотя если кто-то захочет помочь потестировать, то вполне можно и даже нужно.

А насколько точно получится воплотить этот план в жизнь, зависит от того, сколько свободного времени будет у меня и Giovanni Mariani (То есть прощай выходные и всё такое ). И насколько беспроблемно будет обновление с 4.4 и 4.5 на 4.8. Но если даже не сделаем для народа KDE4 4.8.1, то 4.8.2 точно будет.

Ну а так, KDE4 4.8 в 2010.2 собрать можно и работает сборка 4.8 ОЧЕНЬ быстро. Даже в VirtualBox при включенных эффектах. Скриншот с пруфом работоспособности прилагается.

[olelukoie]

Скоро вообще Qt4 4.8 будет, наверное. Изначально были опасения, что KDE4 4.4.x из официальных репозиториев не будет нормально работать с Qt4 4.8, но вроде нормально работает. Хотя надо ещё потестировать будет, конечно.

Qt4 4.8 нам надо, чтобы перейти на KDE4 4.8. И хотя KDE4 будет лежать в отдельном репозитории, библиотеки общего назначения будут в /basic.

Я только хочу отметить, что торопиться с Qt 4.8 и KDE 4.8 не стоит: в них слишком много багов, я бы подождал как минимум до версии 4.8.1 (обеих компонент). Сужу по использованию Qt 4.8 в мандриве 2010.2 на работе (использую для рабочих проектов и вижу, что то, что нормально работало в Qt 4.7, стало подглючивать с переходом на Qt 4.8) и KDE 4.8 в openSUSE дома.

А уж как разрабы многострадальный dolphin покоцали - "ни в сказке сказать, ни вслух произнести". Известный по рассылке кукера товарищ Zй (полагаю, что это один и тот же товарищ, судя по имени и стилю постов) в KDE-шной багзилле на эту тему очень бурную деятельность развел. Кое-что разрабы обещают вернуть в 4.8.1, но только через правку текстовых конфигов, или ждать версии 4.9.

[Pulfer]

Я только хочу отметить, что торопиться с Qt 4.8 и KDE 4.8 не стоит: в них слишком много багов, я бы подождал как минимум до версии 4.8.1 (обеих компонент).

Да, пожалуй...

[VictorR2007]

Вот дела. Тут понадобилось поставить Мандрива 2008.1, но похоже что реп для неё уже нет.
Вроде только остались обновления для main на некоторых зеркалах.
Если не найду, придется ставить 2008.

[verg]

VictorR2007,
Тут посмотрите: ftp://distrib-coffee.ipsl.jussieu.fr/pub/...updates/2008.1/

[VictorR2007]

VictorR2007,
Тут посмотрите: ftp://distrib-coffee.ipsl.jussieu.fr/pub/...updates/2008.1/

Да смотрел. Каталог 2008.1 есть, но как и везде он пуст.

[verg]

VictorR2007,
Тут посмотрите: ftp://distrib-coffee.ipsl.jussieu.fr/pub/...updates/2008.1/

Да смотрел. Каталог 2008.1 есть, но как и везде он пуст.

А если чуть дальше погулять по каталогам: ftp://distrib-coffee.ipsl.jussieu.fr/pub/...a/main/updates/

[VictorR2007]

А если чуть дальше погулять по каталогам: ftp://distrib-coffee.ipsl.jussieu.fr/pub/...a/main/updates/

Я его видел, но сбивает с толку отсутствие других каталогов.
Возможно вы правы. В этом каталоге 2600 файлов.
Может они покроют основное необходимое.
И возможно поможет подключение источников 2008.0.
Беда в том, что нужно ставить на ноутбук в другом городе.
И все через скайп.
Начинаю склоняться к установке 2008.0, хотя брат уже скачал 2008.1 через GPRS.
Будет ругаться.