From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Authentication-Warning: pc213.sam-solutions.net: ed set sender to ed@altlinux.ru using -f X-Comment-To: Sergey Vlasov To: ALT Linux kernel packages development Subject: Re: [d-kernel] Re: lm_sensors In-Reply-To: <20030722211043.1cb99189.vsu@altlinux.ru> (Sergey Vlasov's message of "Tue, 22 Jul 2003 21:10:43 +0400") References: <20030721160226.GA24482@basalt.office.altlinux.org> <20030722175101.452b07b1.vsu@altlinux.ru> <20030722194808.2386fc6a.vsu@altlinux.ru> <20030722211043.1cb99189.vsu@altlinux.ru> From: ed@altlinux.ru (Ed V. Bartosh) Organization: ALT Linux Date: Wed, 23 Jul 2003 09:42:46 +0400 Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Portable Code, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit X-BeenThere: devel-kernel@altlinux.ru X-Mailman-Version: 2.1.2 Precedence: list Reply-To: ALT Linux kernel packages development List-Id: ALT Linux kernel packages development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jul 2003 06:43:51 -0000 Archived-At: List-Archive: List-Post: >>>>> "SV" == Sergey Vlasov writes: >> SV> Как будем класть - на место старого kernel-feat-i2c, или на >> SV> всякий случай рядом - kernel-feat-i2c-2.8.0? Багу я вроде >> SV> нашёл... >> На место, конечно. И kernel-source-... назвать нужно как надо, >> если в этом нет тайного смысла. И модули, соответственно. SV> Это i2c-часть - про неё уже столько писано... Сори, я стормозил, думал, что речь идет об lm_sensors. С i2c все понятно, я считаю, что нужно в kernel-feat-i2c, без версии, это рядовой апдейт с 2.7.0 на 2.8.0. SV> lm_sensors, естественно, в kernel-source- (всё-таки sensors или SV> lm_sensors?) и собирать отдельно. Я думаю, что lm_sensors, поскольку никто пока не признался зачем его переименовали. kernel-source-lm_sensors собирать совместно с lm_sensors, как договаривались. SV> Ладно, залил пока то, что есть: SV> 2c569cc54deec87ee63cfc548f355bf4 SV> kernel-feat-i2c-2.8.0-alt1.src.rpm SV> ae13c0bf6aed66896cd2067c0093ebc4 SV> kernel-source-sensors-2.8.0-2.8.0-alt1.src.rpm SV> a574c3d4bc108f729475b044c23a7296 lm_sensors-2.8.0-alt1.src.rpm SV> Объединять буду завтра, если кто-нибудь раньше не успеет :-) Угу, большое спасибо. Кричи сюда, когда будут новости. Я тоже буду собирать, скорее всего, синхронизируемся. >> Попутно вопрос - мне нужно сделать на основе существующего >> sensors-detect его неинтерактивный вариант. Это реально ? Какие >> грабли могут ожидаться ? Он нужен в Сизифе ? SV> У меня sensors-detect вроде бы всегда работал пристойно - даже SV> сообразил, что два устройства, конфликтующие по адресам SV> субклиентов (0x48, 0x49), вместе работать не могут. Никак не SV> пойму, что асусовцы на этой A7V8X налепили - там мало того, что SV> 0x2d - ASB100, ещё на 0x2f что-то есть (sensors-detect видит SV> W83791D, причём регистром 0x4a субклиенты перемещаются - значит, SV> что-то подобное всё-таки по этому адресу есть), и ещё после SV> издевательств над i2c-viapro на тему PEC smbus-arp обнаруживает SV> какую-то непонятную хреновину... Ясно. Проблемы возможны, но в основном должно работать. У меня вопрос был в основном об неинтерактивности - возможно ли добиться приличной степени детектирования ну хотя бы на распространенных чипсетах ? Возможно ли задетектить проблемные вещи и как-то обойти проблемы ? -- Best regards, Ed V. Bartosh