Hello. Karl Hiramoto wrote:
Krzysztof Halasa wrote:
Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> writes:
Normally you get a backtrace when a "nobody cared" message is issued - this should tell you which driver is probably the cause.
Right - or that the other device is the cause (stuck IRQ line). So, Karl, please just post the backtrace.
Krzysztof, you mentioned clearing the IRQ in the platform code, is there an example of this somewhere?
There is a Compact flash on hda connected the the HPT371N, looking at the IDE code it looks like the drive my not be ready, or the drive may raise the IRQ..
As soon as request_irq is called, the IRQ happens.
CCing linux-IDE now, as it may be an issue with this driver.
Backtrace below, sorry about some of the lines being wrapped.
I think i see the problem:
In the platform code, i should save the frequency of 33 Mhz in the correct register.
You mean the PCI frequency?
hpt366: HPT371N chipset detected hpt366 0000:00:01.0: IDE controller (0x1103:0x0007 rev 0x02) PCI: enabling device 0000:00:01.0 (0140 -> 0141) hpt366 0000:00:01.0: IDE port disabled hpt366 0000:00:01.0: no clock data saved by BIOS hpt366 0000:00:01.0: DPLL base: 77 MHz, f_CNT: 120, assuming 50 MHz PCI
Hum, interesting... is your PCI indeed running at a frequency close to 50 MHz?
hpt366 0000:00:01.0: using 66 MHz DPLL clock hpt366 0000:00:01.0: 100% native mode on irq 28 hda: KINGSTON, ATA DISK drive
MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
