Поставил тут на ноут генту, и заметил такую фигню в логах:
usbcore: registered new interface driver usbmouse
drivers/hid/usbhid/usbmouse.c: v1.6:USB HID Boot Protocol mouse driver
Adding 3927884k swap on /dev/sda2. Priority:-1 extents:1 across:3927884k
spurious 8259A interrupt: IRQ15.
и что самое интересное ноут иногда зависает (вернее как будто замерзает)
на некоторое время, а потом опять работает. Гуглил по этой теме но ничего
дельного не нашёл.
Дистриб гента, ядро 2.6.23-gentoo-r2, проц athlon semprone 3500+, мать на
nforce (NFORCE-MCP51: chipset revision 161), видео geforce go 6100.
Заранее спасибо!!!
The 8259 generates spurious interrupts in response to a number of conditions.
The first is an IRQ line being deasserted before it is acknowledged. This may occur due to noise on the IRQ lines. In edge triggered mode, the noise must maintain the line in the low state for 100nS. When the noise diminishes, a pull-up resistor returns the IRQ line to high, thus generating a false interrupt. In level triggered mode, the noise may cause a high signal level on the systems INTR line. If the system sends an acknowledgment request, the 8259 has nothing to resolve and thus sends an IRQ7 in response. This first case will generate spurious IRQ7's.
A similar case can occur when the 8259 unmask and the IRQ input deassertion are not properly synchronized. In many systems, the IRQ input is deasserted by an I/O write, and the processor doesn't wait until the write reaches the I/O device. If the processor continues and unmasks the 8259 IRQ before the IRQ input is deasserted, the 8259 will assert INTR again. By the time the processor recognizes this INTR and issues an acknowledgment to read the IRQ from the 8259, the IRQ input may be deasserted, and the 8259 returns a spurious IRQ7.
The second is the master 8259's IRQ2 is active high when the slave 8259's IRQ lines are inactive on the falling edge of an interrupt acknowledgment. This second case will generate spurious IRQ15's, but is very rare.