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. > > Conke, care to educate us a bit here? > The really funny part is that it works for some if they use: pci=noacpi,irqpoll - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 6ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 4ata3.00: qc timeout (cmd 0xec) 4ata3.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. Conke, care to educate us a bit here? The really funny part is that it works for some if they use: pci=noacpi,irqpoll - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading both the pata_atiixp and the ahci driver causes problems
Tejun Heo wrote: Please take a look at the JMB quirk in drivers/pci/quirks.c in the latest libata-dev#upstream tree for details. For interest, I will, thanks for the info. Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading both the pata_atiixp and the ahci driver causes problems
Hello, Jon. Jon Masters wrote: >> 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. Dunno about the history. Oh well, as long as the problem gets fixed. > 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. Not sure whether it applies to sb600 directly but libata policy for this type of situation is.. * always prefer the native / more capable (read ahci) interface over emulated SFF interface. * program the device and update PCI header using a PCI quirk such that module loading order or BIOS setting doesn't affect which driver gets attached. Note that if the controller needs to programmed in specific way, the quirk also needs to be called during resume. In this case, the function for SFF interface can simply be disabled. Please take a look at the JMB quirk in drivers/pci/quirks.c in the latest libata-dev#upstream tree for details. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading both the pata_atiixp and the ahci driver causes problems
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. Conke, care to educate us a bit here? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading both the pata_atiixp and the ahci driver causes problems
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: 6ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 4ata3.00: qc timeout (cmd 0xec) 4ata3.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. Conke, care to educate us a bit here? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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: 6ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 4ata3.00: qc timeout (cmd 0xec) 4ata3.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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading both the pata_atiixp and the ahci driver causes problems
Hello, Jon. Jon Masters wrote: 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. Dunno about the history. Oh well, as long as the problem gets fixed. 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. Not sure whether it applies to sb600 directly but libata policy for this type of situation is.. * always prefer the native / more capable (read ahci) interface over emulated SFF interface. * program the device and update PCI header using a PCI quirk such that module loading order or BIOS setting doesn't affect which driver gets attached. Note that if the controller needs to programmed in specific way, the quirk also needs to be called during resume. In this case, the function for SFF interface can simply be disabled. Please take a look at the JMB quirk in drivers/pci/quirks.c in the latest libata-dev#upstream tree for details. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading both the pata_atiixp and the ahci driver causes problems
Tejun Heo wrote: Please take a look at the JMB quirk in drivers/pci/quirks.c in the latest libata-dev#upstream tree for details. For interest, I will, thanks for the info. Jon. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading both the pata_atiixp and the ahci driver causes problems
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 :-) Jon. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Loading both the pata_atiixp and the ahci driver causes problems
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? (This is kernel 2.6.21-rc, and it's almost certainly happening in 2.6.20 as well.) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Loading both the pata_atiixp and the ahci driver causes problems
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: 6ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 4ata3.00: qc timeout (cmd 0xec) 4ata3.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? (This is kernel 2.6.21-rc, and it's almost certainly happening in 2.6.20 as well.) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Loading both the pata_atiixp and the ahci driver causes problems
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: 6ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) 4ata3.00: qc timeout (cmd 0xec) 4ata3.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 :-) Jon. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
