Изпечатай

[PAIN1]

Сега инсталирам слак10.2.
Със стандартното ядро 2.4.31 като копирам от (например) единия хард на другия хард цпуто си стои в ниските проценти и си копира с нормална скорост.Така и трябва да е.
Добре но като сложа 2.6.13 който пак е от диска на слак-а не е така.Копира сравнително по-бавно и държи на 100% цпу-то и бави останалите процеси.
Със слак 10.0 и 2.6.9 пак беше така, но сам го конфигурирах и бях обеден че нещо съм осрал.
Но сега е готово от пакета ...... ?
Някакви идеи и решения ?
Аз така като го гледам ми прилича на изключено дма, обаче

Примерен код

bash-3.00# hdparm /dev/hda /dev/hda:  multcount    =  0 (off)  IO_support   =  1 (32-bit)  unmaskirq    =  1 (on)  using_dma    =  1 (on)  keepsettings =  0 (off)  readonly     =  0 (off)  readahead    = 256 (on)  geometry     = 16383/255/63, sectors = 156301488, start = 0 bash-3.00# hdparm /dev/hdb /dev/hdb:  multcount    =  0 (off)  IO_support   =  1 (32-bit)  unmaskirq    =  1 (on)  using_dma    =  1 (on)  keepsettings =  0 (off)  readonly     =  0 (off)  readahead    = 256 (on)  geometry     = 39560/16/63, sectors = 39876480, start = 0

включена е ....
Сравних и настройките свързани с IDE/ATA .... на 2.4.31 със 2.6.13 и изглеждат еднакви, всичко необходимо е сложено.
??

[senser]

При мен има същия проблем с Gentoo.  Експериментирал съм с различни кернели от 2.6.13 серията но резултата винаги е същия.  Стигнах до извода, че има проблем с драйвера за SATA за моето дъно с NForce3 chipset.
От друга страна няма логика при 2.4 кернел да не е така ...... Интересен проблем май  '>

да ама не съм със САТА '> и съм с Nforce2 '>

[PAIN1]

И никой няма идея ?

[senser]

Май да ....  '>
Надявам се да ми остане малко време да компилирам един кернел от 2.4 серията и ще постна тук резултати дали има разлика някаква.

[mhydra]

И аз имам проблеми с ядра от серията 2.6.хх.
Даже компютъра ми и забиваше по едно време.
Доколкото разбрах серията 2.6 не е окончателно стабилизирана.
В някаква статия четох че точно затова Патрик Валкердинк казва че най производителните ядра които е билдвал са от 2.4.хх серията, тези от 2.6.хх  не са достатъчно стабилни.
Не знам колко е вчрно обаче.
На мем например ми забива звука в 2.6.хх ядрата. При абсолютно всички ядра ми работи точно 30 -60 минути музиката след което се скапва и започва да върти на едно место. Нищо не помага, дори рммод на модула за звуковата карта.Явно самото ядро си се скапва.
На 2.4 нямам никакви проблеми.

[july]

някой забелязъл ли е дали съмптомите се проявяват когато двете иде-та са на различни канали на контролера?

или дали се проявява при интензивно ползване и на двете устройства (хдд и хдд, хдд и цдром, хдд и цдрв etc..)
или само при трансфер от едното на другото...

ще погледна при мене как е при копиране от цдром-а на хдд-то и при четене от хдд докато цдром си записва нещо...
но по-късно че са няма кой да ми сложи нещо в cd-то'>

[july]

един бърз remote тест...

дд иф=/dev/хда оф=/dev/null

дд папа ~12% от цпу-то...

трансфера си ми е колкото може да пусне хдд-то

при дд иф=/dev/зеро оф=/dev/null

дд лапа 99.6% от цпу-то...

иначе time дд иф=/dev/хда оф=/dev/null bs=1M count=100

е една идея под 3 секунди real time, ако съм в първия гигабъте

интересно е че при пуснато дд от дев хда във дев null, и едновременно друга инстанция на дд, който пък чете от края на диска, не натоварва повече системата, отколкото с една инстанция на дд...
пробвайте при вас как е...

[PAIN1]

От където и да копирам твари на 100% цпу-то. На който контролер и да изместя хдд-то, от цд-рома пак е така.

[july]

с top ли го гледаш?
кое е на 100%?
us:, sy:, ?

us user ли е ?
ако да значи не '>
system е на 100%

[july]

'>
ясно, значи има проблем, но не общ за kernel 2.6.x

при конфигурирането на 2.6 kernel има едни интересни опции:
за dma
за включено по подразбиране dma
за включено dma само на hdd-tata

провери как е при тебе..

Примерен код

[july@sf-m-july ~]$ dmesg | grep -i hda | grep -i dma [17179570.832000]     ide0: BM-DMA at 0x2580-0x2587, BIOS settings: hda:DMA, hdb:DMA [17179572.228000] hda: 78140160 sectors (40007 MB) w/8192KiB Cache, CHS=65535/16/63, UDMA(100) [july@sf-m-july ~]$ dmesg | grep -i hdb | grep -i dma [17179570.832000]     ide0: BM-DMA at 0x2580-0x2587, BIOS settings: hda:DMA, hdb:DMA [17179572.300000] hdb: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, DMA

[PAIN1]

Примерен код

bash-3.00# dmesg | grep -i hda | grep -i dma     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA hda: 156301488 sectors (80026 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100) bash-3.00# dmesg | grep -i hdb | grep -i dma     ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:DMA, hdb:DMA hdb: 39876480 sectors (20416 MB) w/418KiB Cache, CHS=39560/16/63, UDMA(66) bash-3.00# dmesg | grep -i hdc | grep -i dma     ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA hdc: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(25) bash-3.00# dmesg | grep -i hdd | grep -i dma     ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:DMA, hdd:DMA hdd: ATAPI 40X DVD-ROM drive, 256kB Cache, UDMA(33) bash-3.00#

дма-то казах че е включено.Странно.

[petkouzunski]

Преди време намирах тема във форумите на Gentoo, където описваха същия проблем. За жалост не мога да я намера в момента, но си спомням, че трябваше да се компилират някои от нещата, започващи с "CONFIG_BLK_DEV_" в конфига на кернела. Казвам "някои от нещата" заради различните чипесети на дъната (ако говоря глупости ми обяснете, тъй като не сам много на "ТИ" с хардуера). В моя случай трябваше да включа CONFIG_BLK_DEV_VIA82CXXX=y (може и още, но не ги помня) и в момента всичко работи. Ако искате конфига да ядрото ми кажете, ще ви го пейстна.

[iive]

Цитат (PAIN1 @ Окт. 09 2005,16:03)

Примерен код bash-3.00# hdparm /dev/hda /dev/hda:  multcount    =  0 (off)  IO_support   =  1 (32-bit)  unmaskirq    =  1 (on)  using_dma    =  1 (on)  keepsettings =  0 (off)  readonly     =  0 (off)  readahead    = 256 (on)  geometry     = 16383/255/63, sectors = 156301488, start = 0 bash-3.00# hdparm /dev/hdb /dev/hdb:  multcount    =  0 (off)  IO_support   =  1 (32-bit)  unmaskirq    =  1 (on)  using_dma    =  1 (on)  keepsettings =  0 (off)  readonly     =  0 (off)  readahead    = 256 (on)  geometry     = 39560/16/63, sectors = 39876480, start = 0

Би ли дал резултата от `hdparm -i /dev/hd?`
В това което ти си дал се посочва само DMA, но е възможно да става дума за обикновен DMA, а не UDMA.

Пусни копиране и top и виж кой процес товари най-много. Това би  дало отправна точка за причината.
Например ако DMA трансфера дава грешка и препраща данните може да доведе до много високо натоварване. (Това се случва при мен при udma5, udma4 е тип-топ).

Възможно е да има проблем с настройването на режима на канала, ако дисковете работат в различни UDMA режими (особенно 33vs66).