From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 8 Jan 2004 18:32:49 +0200 From: X-Stranger To: community@altlinux.ru Subject: Re: [Comm] USB Flash Travelling Disk Message-Id: <20040108183249.3062d83c.x@linux.by> In-Reply-To: <20040105155221.2bfce79e.x@linux.by> References: <3FEBF5B7.000005.09657@soapbox.yandex.ru> <20040105113034.GA25030@alexpc.oiau.chel.cbr.ru> <3FF962E6.000004.10931@ariel.yandex.ru> <20040105155221.2bfce79e.x@linux.by> Organization: Linux.by X-Mailer: Sylpheed version 0.9.6 (GTK+ 1.2.10; i586-alt-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit X-BeenThere: community@altlinux.ru X-Mailman-Version: 2.1.3 Precedence: list Reply-To: community@altlinux.ru List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 16:33:24 -0000 Archived-At: List-Archive: List-Post: После долгого сбора инфы о том, как же это все работает, выяснилось, в чем дело. Это баг некоторых версий БИОСа, как например на моем Acer TravelMate: USB-controller поддерживает только 9-е прерывание (mask==0x200 -->bit 9), правильно будет запускать его на irq 9, следуя данным БИОСа. Но, как сказал один из разработчиков: "But according to the piix irq router, it's connected to irq 10." Нужно было выяснить, где БИОС врет. Выяснили. Проблему решает следующий патч (ядро версий 2.4): --- 2.4/arch/i386/kernel/pci-irq.c +++ build-2.4/arch/i386/kernel/pci-irq.c @@ -629,6 +629,18 @@ if (dev2->irq && dev2->irq != irq) { printk(KERN_INFO "IRQ routing conflict for %s, have irq %d, want irq %d\n", dev2->slot_name, dev2->irq, irq); + if (!strcmp(msg, "Found")) { + /* ok, the bios lied. Try to recover */ + if (r->set && (dev->class >> 8) != PCI_CLASS_DISPLAY_VGA) { + printk(KERN_ERR "trying set.\n"); + if (r->set(pirq_router_dev, dev2, pirq, dev2->irq)) { + printk(KERN_ERR "set succedded.\n"); + eisa_set_level_irq(dev2->irq); + } else { + printk(KERN_ERR "set failed.\n"); + } + } + } continue; } dev2->irq = irq; Компилим ядро, ставим, перезагружаемся - вуаля! Никаких кофликтов в dmesg даже и не наблюдалось! Как и с PCMCIA. Протестено было на 2.4.21 (за неимением под рукой других версий). Инфа, помогающая обнаружить трабл датирована 2001 годом, почему же в ядре до сих пор не сделано такой поправки? Кто знает, кому из ALT Linux Team надо писать, чтобы такую поправку хотя бы в Альтовское ядро включили? X-Stranger On Mon, 5 Jan 2004 15:52:21 +0200 X-Stranger wrote: > Привет всем! > > На НГ получил в подарок сабж. Все бы клево, но не хотит собака с Линухой работать. > Первоначально система просто висла, пока не выяснилось, что сервис USB конфликтует > с сервисом PCMCIA. После отключения оного система виснуть перестала, а на 12й кон- > сольке при вставке этого брелка появляется следующее: > > hub.c: new USB device 00:04.2-1, assigned address 2 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=2 (error -110) > hub.c: new USB device 00:04.2-1, assigned address 3 > usb_control/bulk_msg: timeout > usb.c: USB device not accepting new address=3 (error -110) > > И ФСЕ. Больше ничего не происходит и система брелка не видит. При повторной вставке > появляется та же хрень, только адреса уже 4 и 5. Манипуляции с usb-uhci и uhci не > помогли, детальный поиск по архивам рассылок АЛЬТа решение проблемы тоже не принес. > Двухчасовой поиск по Сети пока результатов тоже не дал. > > Кто знает, как заставить систему видеть и монтировать брелок? Как убрать конфликт > с PCMCIA? > > Система: ALM, апгрейд до Сизифа. Ядро системы: 2.4.22-std-up-alt12. > > Заранее благодарен, Икс. > > P.S. Все конфигурационные файлы и ты ды прилагаются. >