Re: lug-bg: Slackware 10.0 SMP IRQ Проблеми

[George Danchev <danchev@xxxxxxxxx>]

On Tuesday 03 August 2004 18:06, Nikolay Tenev wrote:
> Georgi Chorbadzhiyski wrote:
> > Опитай да boot-неш със опция noapic към ядрото.
>
> Не става. Нито с noapic, нито с nolapic, нито и с двете заедно. Всъщност
> когато boot-на със noapic има разлика. Във /proc/interrupts в колоната за
> втория процесор (CPU1) ми показва само 0 изключение на реда LOC: ( там
> стойността е сходна със тази на полето CPU0) и в следващата колона вместо
> IO-APIC-xxx пише XT-PIC. Обаче ред за eth0 няма. Иначе по време на
> зареждане казва че eth0 е на IRQ 11. Този път вдига картата (виждам я със
> ifconfig - ip, netmask, broadcast и т.н.) но пусна ли ping до gateway -
> всичко умира по същия начин. Иначе сама до себе си има ping, но предполагам
> че това е защото минава през lo.
>
> Също така други 2 реда ми направиха впечатление по време на зареждане:
>
> PCI: Found IRQ 11 for device 00:11.0
> PCI: Sharing IRQ 11 with 00:07.2
>
> (Ако е без noapic редовете са същите но IRQ-то е 19)
>
> 00:11.0 е мрежовата карта
> 00:07.2 USB Controler: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
>
> Реших да пробвам да заредя модулите usb-uhci или uhci. И в двата случая
> излизаше същата грешка (Oops)
> Като има 3 реда текст които казват:

ако искаш да поддържаш различен хардуер с драйвери на модули (както казваш в 
предното msg), то самите модули би трябвало да поддържат опции за irq= , 
io= ... и т.н. при зареждане, така, че след като е свършила процедурата по 
irq routing при зареждането на ядторо и потребителя види какво е заето, то да 
му се даде възможност да зададе други/свободни стойности.

> Unable to handle kernel NULL pointer dereference at virtual address
> 000001cb (тази стойност винаги е различна)
>
> <0> Kernel panic: Aiee, killing interrupt handler !
> In interrupt handler - not syncing

Нищо чудно да си попаднал на smp-unsafe части от ядрото (драйвери)... или 
неправилно използване на функцията BUG() в ядрото или просто някой девелопър 
е забравил, че я извиква в някоя част на кода, където е дебугвал... пиши на 
LKML ако е спешен проблема.

> А иначе под Windows и двете ( eth и usb) са пак на едно и също IRQ
> (обикновенно 19) и работят ... има и мрежа, и usb клавиатура работи

това според мен, не е feature, а bug и ще се прояви съвсем случайно и без 
основание за потребителя... но не се види от всички де...

> И още нещо:
> когато давам modprobe някой от usb модулите се появява и ред:
> kernel BUG at /usr/src/linux-2.4.26/include/asm/spinlock.h:133!

е тука в този файл на 133-ти ред що се извиква BUG() след тази проверка - един 
господ знае ... можеш да я коментираш ( функцията BUG() де) и рекомпайл ... 
ама незнам доколко е sane & safe просто да се коментира BUG() и да не се 
предприеме нищо друго след като сравнението в проверката излезе вярно.
А иначе BUG() си е фукнция на ядторо, но понякога се извиква неправилно или 
прибързано в кода на ядрото от някой ядрени програмисти... демек достигнато е 
до критична ситуация, но положението не се е скофтило чак до там, че да се 
убива машината умишлено .. почти винаги може да се предприеме нещо за да не 
се влиза в тази част от кода или ако все пак се влезе да се изпълни нещо 
смислено вместо BUG() ... но програмиста може да не е знаел какво е то. Ask 
LKML.

-- 
pub 4096R/0E4BD0AB  2003-03-18  <keyserver.bu.edu ; pgp.mit.edu>
fingerprint 1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================