linux-kernel - Re: [git patches] libata fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/