[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <45F4F395.1050708@gmail.com>
Date: Mon, 12 Mar 2007 15:30:45 +0900
From: Tejun Heo <htejun@...il.com>
To: justin@...cron.com
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
Paul Rolland <rol@...917.net>, 'Jeff Garzik' <jeff@...zik.org>,
Alan Cox <alan@...hat.com>,
'Andrew Morton' <akpm@...ux-foundation.org>,
linux-ide@...r.kernel.org, 'LKML' <linux-kernel@...r.kernel.org>,
"'Eric D. Mudama'" <edmudama@...il.com>
Subject: Re: [git patches] libata fixes
Of course I forgot to CC. :-) Quoting whole message for Justin.
Tejun Heo wrote:
> Hello, Linus.
>
> Linus Torvalds wrote:
>> On Sun, 11 Mar 2007, Paul Rolland wrote:
>>> My machine is having two problems : the one you are describing above,
>>> which is due to a SIL controler being connected to one port of the ICH7
>>> (at least, it seems to), and probing it goes timeout, but nothing is
>>> connected on it.
>> Ok, so that's just a message irritation, not actually bothersome
>> otherwise?
>
> It involves a long timeout, so it's bothersome. This is caused by
> Silicon Image 4726/3726 storage processor (SATA Port Multiplier with
> extra features) attached to one of the ICH ports.
>
> If the first downstream port in the PMP is empty and it gets reset in
> non-PMP way, it identifies itself as "Config Disk" of quite small size.
> It's probably used to configure the extra features using standard ATA
> RW commands. Anyways, this "Config Disk" is a bit peculiar and doesn't
> work very well with the current ATA reset sequence and gets identified
> only after a few failures thus causing long timeout.
>
> I keep forgetting about this. I'll ask SIMG how to deal with this. For
> the time being, connecting a device to the PMP port should remove the
> timeouts.
>
>>> The second problem is a Jmicron363 controler that is failing to detect
>>> the DVD-RW that is connected, unless I use the irqpoll option as Tejun has
>>> suggested.
>> .. and this one has never worked without irqpoll?
>>
>>> But, as you suggest it, I'm adding pci=nomsi to the command line....
>>> rebooting... no change for this part of the problem.
>>>
>>> OK, the /proc/interrupt for this config, and the dmesg attached.
>>>
>>> 3 [23:22] rol@...i:~> cat /proc/interrupts
>>> CPU0 CPU1
>>> 0: 297549 0 IO-APIC-edge timer
>>> 1: 7 0 IO-APIC-edge i8042
>>> 4: 13 0 IO-APIC-edge serial
>>> 6: 5 0 IO-APIC-edge floppy
>>> 8: 1 0 IO-APIC-edge rtc
>>> 9: 0 0 IO-APIC-fasteoi acpi
>>> 12: 126 0 IO-APIC-edge i8042
>>> 14: 8313 0 IO-APIC-edge libata
>>> 15: 0 0 IO-APIC-edge libata
>>> 16: 0 0 IO-APIC-fasteoi eth1, libata
>> So it's the irq16 one that is the Jmicron controller and just isn't
>> getting any interrupts?
>>
>> Since all the other interrupts work (and MSI worked for other
>> controllers), I don't think it's interrupt-routing related. Especially as
>> MSI shouldn't even care about things like that.
>>
>> And since it all works when "irqpoll" is used, that implies that the
>> *only* thing that is broken is literally irq delivery.
>>
>> Is there possibly some jmicron-specific "enable interrupts" bit?
>
> (cc'ing Justin of JMicron. Hello, please correct me if I'm wrong.)
>
> Not that I know of. The PATA portion of JMB controllers is bog standard
> PCI BMDMA ATA device where ATA_NIEN is the way to turn IRQ on and off.
>
> Thanks.
>
--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists