linux-kernel - Re: Loading both the pata_atiixp and the ahci driver causes problems

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:	Sun, 18 Mar 2007 02:28:10 -0400
From:	Jon Masters <jonathan@...masters.org>
To:	Tejun Heo <htejun@...il.com>
CC:	Chuck Ebbert <cebbert@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Jeff Garzik <jgarzik@...ox.com>, linux-ide@...r.kernel.org,
	Conke Hu <conke.hu@...il.com>
Subject: Re: Loading both the pata_atiixp and the ahci driver causes problems

Tejun Heo wrote:
> Jon Masters wrote:
>> Chuck Ebbert wrote:
>>
>>> If you try to load both the pata_atiixp and the ahci driver
>>> (for the same ATI SB600 adapter), very strange things happen.
>>> The AHCI driver churns for three minutes or so, spewing
>>> messages like this, then nothing works:
>>>
>>> <6>ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
>>> <4>ata3.00: qc timeout (cmd 0xec)
>>> <4>ata3.00: failed to IDENTIFY (I/O error, err_mask=0x104)
>>> Shouldn't it be able to tell the device has already been
>>> claimed by some other driver?
>> One would assume it'd fail to grab the PCI IO ranges twice? I haven't
>> looked at the code but I have seen this bug mentioned elsewhere so I
>> might well end up having to do that yet :-)
> 
> Dunno much about sb600 but ahci and pata_atiixp are probably using
> separate IO regions && separate PCI functions.

Yeah. I actually thought about this whole issue a bit more recently - 
things like SATA/PATA interference when you've got a part that emulates 
legacy functionality so can appear as two different kinds of device - 
since I don't think my brain was really bothering to listen before. 
Words were going in, but it chose to ignore what was being said.

Only thing that comes to mind is in-driver logic/driver loading ordering 
hack combinations. At least if you've got loadable modules, you've got a 
fighting chance of fixing this kind of situation - built-in and you need 
to fight with whatever ordering exists in the array of init functions.

Jon.

P.S. Guess this means I need to admit I was wrong and apologize to 
Zaitcev sometime too in relation to another discussion...bah :P

-
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/