nForce2 and Linux summary

Marinavo_0507

для интересующихся


Subject: Re: IO-APIC on nforce2 [PATCH] + [PATCH] for nmi_debug=1 + [PATCH]

 for idle=C1halt, 2.6.5

From: Arjen Verweij <A.ewi.tudelft.nl>

X-Mailing-List:         linux-vger.kernel.org

Message-ID: <Pine.GHP.4.44.0404271807470.6154-elektron.its.tudelft.nl>

Hello,

I'm sorry for the small interlude in this thread, but I just want to get

something clear.

Basically we have a problem that is all around, except for (some) Shuttle

boards. Noone really knows what's going on, or at least if they know they

are not vocal about it.

In comes Ross Dickson. He starts poking at the problem until he comes up

with two patches. Near the end of 2003, an NVIDIA engineer (Allen Martin)

states that he (or maybe NVIDIA as a whole?) has been unable to reproduce

this weird problem with hard locks, seemingly related to APIC and IO.

He can tell us there was a bug in a reference BIOS that NVIDIA sent out

into the world, but that it has been fixed in a follow-up. Somewhere at

the start of December, Shuttle updates its BIOS for the AN35. Jesse Allen

flashes the new BIOS into his board and for reasons unknown his hard lock

problem has vanished. The importance of the update of NVIDIA's reference

BIOS in relation to the Shuttle update of the BIOS for their product(s) is

unknown as well.

Meanwhile, Ross Dickson drops requests for support tickets at AMD and

NVIDIA. Until this day, no reply yet. Unaffected by the deafening silence

he keeps improving his patches which seem to work(tm).

Without Ross' hard labor one can avoid the hard locks by banning APIC

support from the kernel, or turn off the C1 disconnect feature in the

BIOS, which is misinterpreted by one ACPI developer as running the CPU

"out of spec."

Recently Len Brown, the ACPI Linux kernel maintainer and Intel employee -

can you spot the irony? - agrees to attempt to reproduce the problem.

After having his box run with cat /dev/hda > /dev/null for a night

straight no lockup has occured. The brand of his motherboard is Shuttle.

Did I mention irony...?

Although this topic is primarily about nforce2 chipsets, similar problems

have been reported with SiS chipsets for AMD cpus. Other chipsets capable

of having the CPU disconnect include VIA KT266(A KT333 and KT400. For

linux a tool like athcool can set the bits for the disconnect and the HLT

instruction. It is unconfirmed that these chipsets suffer from the same

symptoms as nforce2 chipsets.

Does anyone have some input on how to tackle this problem? The only things

I can come up with is mailing all the motherboard manufacturers I can

think of, harass NVIDIA and/or AMD some more through proper channels (i.e.

file a "bug report", but I don't expect much from this, sorry Allen) or

buy Len the cheapest broken nforce2 board I can find at pricewatch.com and

have it shipped to his house :)

Best regards,

Arjen

Marinavo_0507

типа вроде как finally resolved


From: Allen Martin <nvidia.com>

Subject: RE: IO-APIC on nforce2 [PATCH] + [PATCH] for nmi_debug=1 + [PATCH] for

 idle=C1halt, 2.6.5

Message-ID: <DCB9B7AA2CAB7F418919D7B59EE4mail-sc-6-bk.nvidia.com>

I'm happy to be able to make this information public to the Linux

community.  This information has been previously released to BIOS /

board vendors as an appnote, but in the interest of getting a workaround

into the hands of users the quickest we're making it public for possible

inclusion into the Linux kernel.

Problem:

C1 Halt Disconnect problem on nForce2 systems

Description:

A hang is caused when the CPU generates a very fast CONNECT/HALT cycle

sequence.

Workaround:

Set the SYSTEM_IDLE_TIMEOUT to 80 ns. This allows the state-machine and

timer to return to a proper state within 80 ns of the CONNECT and probe

appearing together.

Since the CPU will not issue another HALT within 80 ns of the initial

HALT, the failure condition is avoided.

This will require changing the value for register at bus:0 dev:0 func:0

offset 6c.

Chip   Current Value   New Value

C17       1F0FFF01     1F01FF01

C18D      9F0FFF01     9F01FF01

Northbridge chip version may be determined by reading the PCI revision

ID (offset 8) of the host bridge at bus:0 dev:0 func:0.  C1 or greater

is C18D.

дальше идут патчи и радостные возгласы жертв

sergey_m

Ну это не причина покупать такие матери

Marinavo_0507

правильно
причина в том, что они ох№%нно дешёвые и быстрые
если не пользоваться набортными ide и ethernet (вследствии секретности документации
то покатит имхо

Gasparfx

Блин, у меня именно эта херня и была: Мат. плата у меня Gigabyte с nForce2. В Линуксе никак не хотел устанавливаться звук, т.е. он конечно был, но какой то странный, играл неестесственно быстро и рывками. Трахался очень долго, перерыл кучу man' ов, howto, и поисковиков. В конце концов обнаружил в ошибках ядра такие строки:
..MP-BIOS bug: 8254 timer not connected to IO-APIC
Nvaudio: drain_dac, dma timeout?
Короче, перекомпилировал ядро, отключив поддержку APIC, вроде всё работает нормально, правда появляются иногда странные сообщения, типа: spurious 8259A interrupt: IRQ7.
Не подскажешь, где именно лежат нужные патчи?

Marinavo_0507

> Блин, у меня именно эта херня и была
не эта
у тебя обычная кривизна драйверов
а с чего бы им быть прямыми?
если установка последнего ядра не помогает, купи нормальную звуковуху

Gasparfx

А причём тут звуковуха? Насколько я понял, проблема была в ядре, которое не могла присвоить через APIC нормальный IRQ таймеру 8254. Вследствие этого, звуковая карта не могла нормально синхронизировать звуковой поток. Кстати, в mplayer' е звук был нормальный, видимо потому, что он синхронизируется через RTC.

Marinavo_0507

ну тогда просто обновить ядро и биос, если ещё не
в любом случае, проблема другая
Оставить комментарий
Имя или ник:
Комментарий: