Linux 2.6.14.3

Наконец-то новое ядро!

Судя по ченжлогу мне обновляться не надо. Буду ждать 2.6.15 с нормальной поддержкой ipw2200

скромно, ничего интересного...

>Author: Oleg Nesterov <oleg@tv-sign.ru>

Хех.. приятно видеть, что кто-то из наших там засветился :))))

С утра ядро не обвновил - день пропал... я только 2.6.8 поставил...

а я вчера на 2.6.11 откатился с 12-го

>а я вчера на 2.6.11 откатился с 12-го

А что там? Я как раз собирался .11 на что-нибудь поновее проапгрейдить.

И по традиции:

Ну теперь-то виндовсу конец!!

А чё в 2.6.14 какие-то проблемы с этими дровами

а если я обновлюсь на 2.6.14.3 моя девушка от меня не уйдет к другому, у кого 2.4.32 ???

[PATCH] x86_64/i386: Compute correct MTRR mask on early Noconas

О ну надо же... Я на эту багу еще в 2.6.12 наступал - мат в dmesg от mtrr и отпадание fglrx на процессоре с поддержкой 40-битных физ. адресов.

> а если я обновлюсь на 2.6.14.3 моя девушка от меня не уйдет к другому, у кого 2.4.32 ???

Она уйдёт к тому, у кого

C:\>ver

Microsoft Windows XP [Version 5.1.2600]

:)

Здесь вот у человека тоже с радеоном проблема.

http://www.linux.org.ru/jump-message.jsp?msgid=1169145

Может быть это ему и поможет?

тогда херово "греют батареи"

>>а я вчера на 2.6.11 откатился с 12-го

> А что там? Я как раз собирался .11 на что-нибудь поновее проапгрейдить.

то опять сата, то медленно на мою флешку копирует (20 KB/s)

>то опять сата, то медленно на мою флешку копирует (20 KB/s)

Что с сата? И какой у тебя контроллер? А тормоза с флешкой - это скорее всего фича. По умолчанию они включают режим usb 1. Впрочем, мне неактуально - у меня usb1 до сих пор.

Intel мудилы клепают глюкавые ля процы:

Q23 X Plan Fix Incorrect Physical Address Size Returned by CPUID Instruction

Q23.
Incorrect Physical Address Size Returned by CPUID Instruction
Problem:
The CPUID instruction Function 80000008H (Extended Address Sizes Function) returns the address
sizes supported by the processor in the EAX register. This Function returns an incorrect physical address
size value of 40 bits. The correct physical address size is 36 bits.
Implication: Function 80000008H returns an incorrect physical address size value of 40 bits.
Workaround: None identified.
Status:
For the steppings affected, see the Summary Tables of Changes.

Урроды ля. А тут ваще кашмар http://www.intel.com/design/Pentium4/specupdt/302352.htm

Q3 X X NoFix Processor may hang due to Speculative Page Walks to Non-
Existent System Memory

Q9 X X NoFix System bus interrupt messages without data and which receive a HardFailure response may hang the processor

Q14 X X NoFix Shutdown and IERR# may result due to a Machine Check
Exception on a Hyper-Threading technology enabled processor

Q15 X X NoFix Processor may hang under certain frequencies and 12.5%
STPCLK# duty cycle

Q17 X X NoFix A write to APIC Task Priority Register (TPR) that lowers priority may seem to have not occurred

Q19 X X NoFix Parity Error in the L1 Cache may cause the processor to hang

Q21 X Fixed Locks and SMC Detection May Cause the Processor to
Temporarily Hang

Q27 X X NoFix Memory Aliasing of Pages as Uncacheable Memory Type and
Write Back (WB) May Hang the System

Q30 X Plan Fix STPCLK# Signal Assertion under Certain Conditions May Cause a System Hang

Q32 X X NoFix Using STPCLK and Executing Code From Very Slow Memory
Could Lead to a System Hang

Q38 X X NoFix Recursive Page Walks May Cause a System Hang

Q45 X X Plan Fix Execution of IRET or INTn Instructions
May Cause Unexpected System Behavior

Q51 X Plan Fix Processor May Hang when Resuming from Deep Sleep State


Интеля ля муйня ля гребаная #%&^%#&%&#%&#%

Интересно, у AMD дела получше в этом плане или такиеже глючные поделки?

В общем-то этот баг не такой страшный как f0 0f на первых пнях. Лажается интел частенько. С одной стороны - не ошибается тот, кто ничего не делает, но с другой - у AMD таких фатальных багов я что-то не припомню.

>А тормоза с флешкой - это скорее всего фича.

Это не фича

Device Drivers -> Block Devices -> Low Performance USB Block driver (No)

>В общем-то этот баг не такой страшный как f0 0f на первых пнях. Лажается интел частенько.

Да, возможно, только вот он каким боком вылазил:

$ cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=983552MB: write-back, count=1 $ dmesg|grep -i mtrr mtrr: v2.0 (20020519) mtrr: type mismatch for c0000000,1000000 old: write-back new: write-combining mtrr: type mismatch for c0000000,800000 old: write-back new: write-combining mtrr: type mismatch for c0000000,400000 old: write-back new: write-combining mtrr: type mismatch for c0000000,200000 old: write-back new: write-combining mtrr: type mismatch for c0000000,100000 old: write-back new: write-combining mtrr: type mismatch for c0000000,80000 old: write-back new: write-combining mtrr: type mismatch for c0000000,40000 old: write-back new: write-combining mtrr: type mismatch for c0000000,20000 old: write-back new: write-combining mtrr: type mismatch for c0000000,10000 old: write-back new: write-combining mtrr: type mismatch for c0000000,8000 old: write-back new: write-combining mtrr: type mismatch for c0000000,4000 old: write-back new: write-combining mtrr: type mismatch for c0000000,2000 old: write-back new: write-combining mtrr: type mismatch for c0000000,1000 old: write-back new: write-combining mtrr: type mismatch for c0000000,8000000 old: write-back new: write-combining [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22) mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining $ grep -i "DRI init" /var/log/Xorg.0.log (WW) fglrx(0): * DRI initialization failed! * $

>С одной стороны - не ошибается тот, кто ничего не делает, но с другой - у AMD таких фатальных багов я что-то не припомню.

Не ошибается тот кто ничго не делает это да, но так и любой глюкодром можно оправдать, профессионал тем от чайника и отличается, что ошибки делает намного реже...

>В общем-то этот баг не такой страшный как f0 0f на первых пнях.
Лажается интел частенько.

Да, возможно, только вот он каким боком вылазил:

$ cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=983552MB: write-back, count=1
$ dmesg|grep -i mtrr
mtrr: v2.0 (20020519)
mtrr: type mismatch for c0000000,1000000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,800000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,400000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,200000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,100000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,80000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,40000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,20000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,10000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,8000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,4000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,2000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,1000 old: write-back new: write-combining
mtrr: type mismatch for c0000000,8000000 old: write-back new: write-combining
[fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)
mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
$ grep -i "DRI init" /var/log/Xorg.0.log
(WW) fglrx(0): * DRI initialization failed! *
$

>С одной стороны - не ошибается тот, кто ничего не делает, но с другой
- у AMD таких фатальных багов я что-то не припомню.

Не ошибается тот кто ничго не делает это да, но так и любой глюкодром
можно оправдать, профессионал тем от чайника и отличается, что ошибки
делает намного реже...

[PATCH] ctnetlink: Fix oops when no ICMP ID info in message

This patch fixes an userspace triggered oops. If there is no ICMP_ID
info the reference to attr will be NULL.


Лол, линуск глючный =)))))) Remote ICMP kernel oops.

[PATCH] ctnetlink: Fix oops when no ICMP ID info in message

This patch fixes an userspace triggered oops. If there is no ICMP_ID
info the reference to attr will be NULL.


Лол, линуск глючный =)))))) Remote ICMP kernel oops

Предлагаю, сделать раздел с названием "Мир Дыр Линукса" и помещать туда ежедневные нововсти о 2.6.14.1, 2.6.14.2, 2.6.14.3 2.6.14.3 2.6.14.4-pre1 и других бесполезных числах, так же там будут обсуждать как кто с какого и до какого ядра обновился и как теперь им хорошо...

> Что с сата? И какой у тебя контроллер?

встроенный в i865, мать ASUS P4P800, но я думаю, что это сборщики rpm-ки немного напортачили

а вот с USB - действительно что-то не так. Флешка и так у меня usb1, но обычно скорость записи 200KB/s, а не 20. Плюс после загрузки с 2.6.12 пропадают симлинки, которые у меня через udev создаются (/etc/udev/rules.d/), загружаюсь с 2.6.11 - наместо возвращаются

Не знаете: У них есть в планах поправить "фишку" с vfat + -o sync? А то если vfat (флешки) монтировать с опцией sync - такие ТОРМОЗА шо жопа (30кбпс на ЮСБ2)! И это они начиная с 2.6.12 кажися (чи 13) такое учудили. Зачем? Приходится мантировать без sync-а, сливать, а потом вручную делать sync - тогда все ОК.

>Это не фича Device Drivers -> Block Devices -> Low Performance USB Block driver (No)

Я и говорю - фича. Причем отключаемая.

>а вот с USB - действительно что-то не так. Флешка и так у меня usb1, но обычно скорость записи 200KB/s, а не 20

Что-то действительно у вас "не так"... На самом разном железе USB1 "давало" 700-900 К/с, USB2 - 20-22 М/с

> А то если vfat (флешки) монтировать с опцией sync

Он монтирует флэшки с опцией sync? А-а-а, держите меня семеро, живой миллионер - меняет флэшки как перчатки...

Кстати с дискетой примерно после 2.6.11 тоже косяки с sync - если монтировать как sync, то тормоза просто ужасные.

> то медленно на мою флешку копирует (20 KB/s)

С sync монтируешь, что ли? Ню-ню, продолжай :)

> Не знаете: У них есть в планах поправить "фишку" с vfat + -o sync? А то если vfat (флешки) монтировать с опцией sync - такие ТОРМОЗА шо жопа (30кбпс на ЮСБ2)! И это они начиная с 2.6.12 кажися (чи 13) такое учудили. Зачем? Приходится мантировать без sync-а, сливать, а потом вручную делать sync - тогда все ОК.

http://bugzilla.kernel.org/show_bug.cgi?id=5308

Убедительно?

мда действительно, при скорости чтения fat c sync 700-900 kb/s
запись c sync на fat 20-60 kb/s
запись без sync на fat 613 kb/s , при этом в mc копируется мгновенно и ждать надо только если сразу umount делать

вот и прорезалась необходимость ускорять vfat, точнее vfat with sync под linuxom.

> при этом в mc копируется мгновенно и ждать надо только если сразу umount делать
А команда $ sync на что дана?

>http://bugzilla.kernel.org/show_bug.cgi?id=5308 Убедительно?
Убедительно, только не понятно почему в версиях <12 этой фишки не было? И с sync писалось быстро и и быстро отмантировалось, как оно тогда работало?

> А команда $ sync на что дана?
вы о чем ? удобнее написать umount и подождать, чем написать sync, подождать, написать umount.

Во всей ветке 2.6.14 на данный момент напрочь сломана поддержка libipq. Точнее, они её реализовали через вызовы функций libnetfilter_queue, которая является интерфейсом к NFQUEUE из iptables.

Но как раз вот этот-то интерфейс и не работает. Точнее работает, но наполовину.

Кто работал с QUEUE - не обновляйтесь, сломается. Welte обещает патчи.

> Убедительно, только не понятно почему в версиях <12 этой фишки не было? И с sync писалось быстро и и быстро отмантировалось, как оно тогда работало?

вот по этому: Handle MS_SYNCHRONOUS flag in FAT: FAT filesystem has been ignoring the "sync" mount option for ages. This patches fixes this, but (obviously) degrades performance unless you mount your FAT filesystem as asynchronous ("async mount option) [ http://wiki.kernelnewbies.org/Linux26Changes ]

Раз уж речь об Интеловских глюках пошла, вот ещё
ссылочка:
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0224.html
Отличие этого глюка, как я понял из обсуждения,
в том, что он ещё с 386 процов идёт, в интеле про
него знали с самого начала, но решили не исправлять.
В результате в LKML решили, что этот баг может
быть причиной "утечки информации" из ядра, и сделали
какой-то сложнейший и геморный ворк-эраунд, после
которого довольно долго всё глючило...

> удобнее написать umount и подождать, чем написать sync, подождать, написать umount.
А automount на что? :)

>удобнее написать umount и подождать, чем написать sync, подождать, написать umount.

Пиши sync && umount =)

А нафига вообще синхронизировать перед umount?!! Она итак отработает sync(2)