[PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Milan Kupcevic]

From: Milan Kupcevic <milan@physics.harvard.edu>

Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4 
(PDC40718-GP) wrong port enumeration order that makes it (nearly) 
impossible to deal with boot problems using two or more drives.

Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
---

The current kernel driver assumes:

port 1 - scsi3
port 2 - scsi1
port 3 - scsi0
port 4 - scsi2

Having 4 hard drives connected to the controller grub recognizes the 
port 1 connected drive as "(hd0)" but kernel recognizes the port 3 
connected drive as scsi0:0:0:0 (/dev/sda). There is no clean way to make 
it boot correctly.

 sata_promise.c |   16 ++++++++++------
 1 files changed, 10 insertions(+), 6 deletions(-)

diff -uprN ./drivers/scsi/sata_promise.c 
../linux/drivers/scsi/sata_promise.c
--- ./drivers/scsi/sata_promise.c       2006-02-17 17:23:45.000000000 -0500
+++ ../linux/drivers/scsi/sata_promise.c        2006-02-24 
19:35:16.000000000 -0500
@@ -707,14 +707,18 @@ static int pdc_ata_init_one (struct pci_
 
        /* notice 4-port boards */
        switch (board_idx) {
-       case board_20319:
+       case board_20319: /* tx4  */
                        probe_ent->n_ports = 4;
 
-               pdc_ata_setup_port(&probe_ent->port[2], base + 0x300);
-               pdc_ata_setup_port(&probe_ent->port[3], base + 0x380);
-
-               probe_ent->port[2].scr_addr = base + 0x600;
-               probe_ent->port[3].scr_addr = base + 0x700;
+               pdc_ata_setup_port(&probe_ent->port[0], base + 0x380);
+               pdc_ata_setup_port(&probe_ent->port[1], base + 0x280);
+               pdc_ata_setup_port(&probe_ent->port[2], base + 0x200);
+               pdc_ata_setup_port(&probe_ent->port[3], base + 0x300);
+
+               probe_ent->port[0].scr_addr = base + 0x700;
+               probe_ent->port[1].scr_addr = base + 0x500;
+               probe_ent->port[2].scr_addr = base + 0x400;
+               probe_ent->port[3].scr_addr = base + 0x600;
                break;
        case board_2037x:
                probe_ent->n_ports = 2;

-- 
Milan Kupcevic
System Administrator
Harvard University
Department of Physics

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Jeff Garzik]

Milan Kupcevic wrote:
> From: Milan Kupcevic <milan@physics.harvard.edu>
> 
> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4 
> (PDC40718-GP) wrong port enumeration order that makes it (nearly) 
> impossible to deal with boot problems using two or more drives.
> 
> Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
> ---
> 
> The current kernel driver assumes:
> 
> port 1 - scsi3
> port 2 - scsi1
> port 3 - scsi0
> port 4 - scsi2

The current kernel driver assumes nothing, but simply exports what the 
hardware gives us.

It sounds like you are trying to patch the kernel because you received 
an incorrectly-wired board.  NAK.

	Jeff

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Milan Kupcevic]

Jeff Garzik wrote:

> Milan Kupcevic wrote:
>
>> From: Milan Kupcevic <milan@physics.harvard.edu>
>>
>> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4 
>> (PDC40718-GP) wrong port enumeration order that makes it (nearly) 
>> impossible to deal with boot problems using two or more drives.
>>
>> Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
>> ---
>>
>> The current kernel driver assumes:
>>
>> port 1 - scsi3
>> port 2 - scsi1
>> port 3 - scsi0
>> port 4 - scsi2
>
>
> The current kernel driver assumes nothing, but simply exports what the 
> hardware gives us.
>
> It sounds like you are trying to patch the kernel because you received 
> an incorrectly-wired board.  NAK.
>
>     Jeff
>

I have tested two SATAII150TX4 (chip PDC40518 id: 105a:3d18 (rev 02)) 
adapters and one SATA300TX4 (chip PDC40718-GP id: 105a:3d17 (rev 02)) 
adapter on three different boards in last several days with exactly the 
same results.

The problem disappears when using the driver form the www.promise.com site.

BIOS, Grub and promise.com driver agree the printed and documented port 
order is correct but the current kernel driver exports (wrong) 3-2-4-1 
port order.


Thanks,

Milan

-- 
Milan Kupcevic
System Administrator
Harvard University
Department of Physics

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Eyal Lebedinsky]

Milan Kupcevic wrote:
> From: Milan Kupcevic <milan@physics.harvard.edu>
> 
> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4
> (PDC40718-GP) wrong port enumeration order that makes it (nearly)
> impossible to deal with boot problems using two or more drives.
> 
> Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
> ---
> 
> The current kernel driver assumes:
> 
> port 1 - scsi3
> port 2 - scsi1
> port 3 - scsi0
> port 4 - scsi2

I totally agree with the fact that the Linux driver gets the ports wrong
when compared to the BIOS, Windows and surely contradicts the port
numbers printed on the board. I doubt we all got samples on the one
bad batch...

It *is* a real problem and if the solution is correct then I support it.

Maybe we need a quick feedback from current users: do you guys find
that the ports are detected as they are labelled (white silk screen)
on the board or do they show up out of order (as listed above by
Milan)?

-- 
Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
	attach .zip as .dat

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Christiaan den Besten]

Hi !

We have several of these boards in use [SATA 300 TX4] (bought over time .. not in one batch). All of them have the ordering as 
described below. So another vote for "Please fix!" :)

bye,
Chris

----- Original Message ----- 
From: "Eyal Lebedinsky" <eyal@eyal.emu.id.au>
To: "Milan Kupcevic" <milan@physics.harvard.edu>
Cc: "Jeff Garzik" <jgarzik@pobox.com>; <linux-ide@vger.kernel.org>; <linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>; 
<trivial@rustcorp.com.au>; <torvalds@osdl.org>
Sent: Saturday, February 25, 2006 7:59 AM
Subject: Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4


> Milan Kupcevic wrote:
>> From: Milan Kupcevic <milan@physics.harvard.edu>
>>
>> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4
>> (PDC40718-GP) wrong port enumeration order that makes it (nearly)
>> impossible to deal with boot problems using two or more drives.
>>
>> Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
>> ---
>>
>> The current kernel driver assumes:
>>
>> port 1 - scsi3
>> port 2 - scsi1
>> port 3 - scsi0
>> port 4 - scsi2
>
> I totally agree with the fact that the Linux driver gets the ports wrong
> when compared to the BIOS, Windows and surely contradicts the port
> numbers printed on the board. I doubt we all got samples on the one
> bad batch...
>
> It *is* a real problem and if the solution is correct then I support it.
>
> Maybe we need a quick feedback from current users: do you guys find
> that the ports are detected as they are labelled (white silk screen)
> on the board or do they show up out of order (as listed above by
> Milan)?
>
> -- 
> Eyal Lebedinsky (eyal@eyal.emu.id.au) <http://samba.org/eyal/>
> attach .zip as .dat
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
> 

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Oliver Joa]

Hi,

On Fri, 24 Feb 2006, Milan Kupcevic wrote:

> From: Milan Kupcevic <milan@physics.harvard.edu>
>
> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4 (PDC40718-GP) 
> wrong port enumeration order that makes it (nearly) impossible to deal with 
> boot problems using two or more drives.

I wonder that a lot of people use promise sata 300 tx4. i have lots of 
problems, i always get scsi-errors. now i changed to other harddisk. i use 
seagate, which is on the compatibility-list of this card. so why is it not 
working in my computer. i use kernel 2.6.15. what else can be wrong? I 
have a intel serverboard with dual p3 with 440gx-chipset.

The driver from promise does not compile. Someone out there who got it 
running? What to do?

any idea?

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Oliver Joa]

Hi,

On Fri, 24 Feb 2006, Milan Kupcevic wrote:

> From: Milan Kupcevic <milan@physics.harvard.edu>
>
> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4 (PDC40718-GP) 
> wrong port enumeration order that makes it (nearly) impossible to deal with 
> boot problems using two or more drives.


I wonder that a lot of people use promise sata 300 tx4. i have lots of
problems, i always get scsi-errors. now i changed to other harddisk. i use
seagate, which is on the compatibility-list of this card. so why is it not
working in my computer. i use kernel 2.6.15. what else can be wrong? I 
have a
intel serverboard with dual p3 with 440gx-chipset.

The driver from promise does not compile. Someone out there who got it 
running?
What to do?

any idea?

Thank you very much.

Olli

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Fabian Knittel]

Hi all,

correct me if I'm wrong, but apparently this issue hasn't been taken
care of yet and I've only seen reports of "wrong wiring" ... where
everyone apart from the current linux driver sees correct wiring.

In other words: The boards appear to be wired correctly (or maybe just
uniformly the wrong way) and the bios, the windows driver and the closed
source promise driver (reportedly) know how to handle it.

We have a SATA 150 TX4 board with the same behaviour and would love to
see this annoying little bug fixed in linux. :)

  Fabian

[ More context for reference. (No new text below.) ]
Christiaan den Besten wrote:
> We have several of these boards in use [SATA 300 TX4] (bought over time
> .. not in one batch). All of them have the ordering as described below.
> So another vote for "Please fix!" :)
>
> ----- Original Message ----- From: "Eyal Lebedinsky" <eyal@eyal.emu.id.au>
> To: "Milan Kupcevic" <milan@physics.harvard.edu>
> Cc: "Jeff Garzik" <jgarzik@pobox.com>; <linux-ide@vger.kernel.org>;
> <linux-scsi@vger.kernel.org>; <linux-kernel@vger.kernel.org>;
> <trivial@rustcorp.com.au>; <torvalds@osdl.org>
> Sent: Saturday, February 25, 2006 7:59 AM
> Subject: Re: [PATCH] sata_promise: Port enumeration order - SATA 150
> TX4, SATA 300 TX4
> 
> 
>> Milan Kupcevic wrote:
>>
>>> From: Milan Kupcevic <milan@physics.harvard.edu>
>>>
>>> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4
>>> (PDC40718-GP) wrong port enumeration order that makes it (nearly)
>>> impossible to deal with boot problems using two or more drives.
>>>
>>> Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
>>> ---
>>>
>>> The current kernel driver assumes:
>>>
>>> port 1 - scsi3
>>> port 2 - scsi1
>>> port 3 - scsi0
>>> port 4 - scsi2
>>
>>
>> I totally agree with the fact that the Linux driver gets the ports wrong
>> when compared to the BIOS, Windows and surely contradicts the port
>> numbers printed on the board. I doubt we all got samples on the one
>> bad batch...
>>
>> It *is* a real problem and if the solution is correct then I support it.
>>
>> Maybe we need a quick feedback from current users: do you guys find
>> that the ports are detected as they are labelled (white silk screen)
>> on the board or do they show up out of order (as listed above by
>> Milan)?
-- 
avona media GbR      | Neureuter Str. 5-7   | D-76185 Karlsruhe
fon +49 721 53169901 | fax +49 721 53169904 | www.avona.com

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Milan Kupcevic]

Fabian Knittel wrote:

>In other words: The boards appear to be wired correctly (or maybe just
>uniformly the wrong way) and the bios, the windows driver and the closed
>source promise driver (reportedly) know how to handle it.
>
>We have a SATA 150 TX4 board with the same behaviour and would love to
>see this annoying little bug fixed in linux. :)
>
>  Fabian
>
>Christiaan den Besten wrote:
>  
>
>>We have several of these boards in use [SATA 300 TX4] (bought over time
>>.. not in one batch). All of them have the ordering as described below.
>>So another vote for "Please fix!" :)
>>
>>    
>>
>>>Milan Kupcevic wrote:
>>>
>>>      
>>>
>>>>From: Milan Kupcevic <milan@physics.harvard.edu>
>>>>
>>>>Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4
>>>>(PDC40718-GP) wrong port enumeration order that makes it (nearly)
>>>>impossible to deal with boot problems using two or more drives.
>>>>
>>>>Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
>>>>---
>>>>
>>>>The current kernel driver assumes:
>>>>
>>>>port 1 - scsi3
>>>>port 2 - scsi1
>>>>port 3 - scsi0
>>>>port 4 - scsi2
>>>>        
>>>>
>>>I totally agree with the fact that the Linux driver gets the ports wrong
>>>when compared to the BIOS, Windows and surely contradicts the port
>>>numbers printed on the board. I doubt we all got samples on the one
>>>bad batch...
>>>
>>>It *is* a real problem and if the solution is correct then I support it.
>>>
>>>Maybe we need a quick feedback from current users: do you guys find
>>>that the ports are detected as they are labelled (white silk screen)
>>>on the board or do they show up out of order (as listed above by
>>>Milan)?
>>>      
>>>

This is a list of Promise SATA TX4 and FastTrak TX4xxx controllers, I 
have in my lab, affected with the "wiring" bug:

Retail name: SATAII150 TX4
Chip label: PDC40518  SATAII150
Vendor-Device number: 105a:3d18 (rev 02)
Wiring: NEW

Retail name: FastTrak TX4200
Chip label: PDC40519  RAID  SATAII150
Vendor-Device number: 105a:3519
Wiring: NEW

Retail name: SATA300 TX4
Chip label: PDC40718-GP  SATAII300
Vendor-Device number: 105a:3d17 (rev 02)
Wiring: NEW


This is the only one Promise TX4 controller, I have in my lab, that is 
working properly regarding the "wiring" bug with the current kernel driver:

Retail name: FastTrak S150 TX4
Chip label: PDC20319 RAID SATA 150
Vendor-Device number: 105a:3319 (rev 02)
Wiring: OLD


This is a list of Promise SATA TX2 and FastTrak TX2xxx controllers, I 
have in my lab, that are working correctly regarding the "wiring" bug 
with the current kernel driver:

Retail name: FastTrak S150 TX2plus
Chip label: PDC20371  SATA 150
Vendor-Device number: 105a:3371 (rev 02)

Retail name: SATA150 TX2plus
Chip label: PDC20375  SATA 150
Vendor-Device number: 105a:3375 (rev 02)

Retail name: FastTrak TX2200
Chip label: PDC20571  SATAII150
Vendor-Device number: 105a:3571 (rev 02)


It seems the problem exists on all newer Promise SATA TX4 and FastTrak 
TX4xxx controllers, so I refer to them as the "new wiring" Promise SATA 
controllers.  All the Promise SATA TX2 and FastTrak TX2xxx I have in my 
lab are working correctly with the current kernel driver, so it seems 
this "wiring" problem does not affect the TX2(xxx) controllers; only 
SATA TX4 and FastTrak TX4xxx are affected.

For driver to be able to distinguish the "new wiring" and the "old 
wiring" Promise TX4(xxx) controllers we need a feedback from the users 
that are aware of this problem.

Q. How to know if a controller has the "new wiring"? 
A. You need to be able to boot your testing machine using a hard drive 
not attached to the controller you are going to test.  Connect 4 
different size/brand/model SATA hard drives to the testing controller so 
you can see the particular order they are recognized by the BIOS and by 
the kernel (not patched for the "new wiring"). 
   Boot the machine and look for the BIOS recognized hard drive order.  
The BIOS recognized hard drive order always matches the order the hard 
drives are connected to, with respect to port number labels.  If you are 
testing FastTrak TX series controller you may need to press Ctrl-F (or 
Ctrl-A) to get into controllers' BIOS and then press "2" to see the BIOS 
recognized order.  Plain SATA models do not have controller specific 
BIOS and they will report the BIOS recognized order without user 
intervention.  You may want to press the "Pause" key on your keyboard to 
have enough time to read the text on the screen.  If you are arguing 
with your machine using a serial terminal, there is a Hold Screen button 
somewhere on the terminal keyboard. 
   When the machine boots up, type "cat /proc/scsi/scsi", it will show 
up the order hard drives are recognized by the kernel.  Make sure the 
kernel you are using is NOT patched for the "new wiring" bug.  If you 
have the "new wiring" case, the order will be 3-2-4-1; that means, the 
drive connected to the "port 3" and recognized as the third drive 
connected to the controller by the BIOS, will be seen by the kernel as 
first hard drive connected to this controller.  The second drive is 
always at second place, the fourth one goes at third place and the first 
one goes at fourth place.


Please respond with this data:

- Your Promise SATA controller retail name
- Chip label (PDCxxxxx)
- PCI vendor and device code as you can get with "lspci -n"
- Say if the controler has the new or the old wiring
 
Your feedback will be appreciated.


NOTE: the patch I have submitted ( 
http://marc.theaimsgroup.com/?l=linux-ide&m=114082978311290&w=2 ) is a 
solution that doesn't know about the older Promise SATA controllers, 
which are not affected with the "new wiring" problem, so the older 
controllers will appear screwed if you use it.

Hopefully we will collect enough info about all the SATA Promise 
controllers to distinguish the new and the old wiring controllers, then 
produce a new patch that will be a correct solution to the "new wiring" 
problem.


The best to all,

Milan

-- 
Milan Kupcevic
System Administrator
Harvard University
Department of Physics

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Fabian Knittel]

Milan Kupcevic wrote:
> Please respond with this data:
> 
> - Your Promise SATA controller retail name
> - Chip label (PDCxxxxx)
> - PCI vendor and device code as you can get with "lspci -n"
> - Say if the controler has the new or the old wiring

We only have one card and it matches one of yours:

  Retail name: SATAII150 TX4
  Chip label: PDC40518  SATAII150
  Vendor-Device number: 105a:3d18 (rev 02)
  Wiring: NEW

Greetings, Fabian
-- 
avona media GbR      | Neureuter Str. 5-7   | D-76185 Karlsruhe
fon +49 721 53169901 | fax +49 721 53169904 | www.avona.com

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Evan Harris]

I have a card that mirrors this one from your list:

Retail name: SATA300 TX4
Chip label: PDC40718-GP  SATAII300
Vendor-Device number: 105a:3d17 (rev 02)

Through testing, I've found linux 2.6.16 and 2.6.17 find the ports in this 
order (the list is ordered by linux detection):

1. silkscreen port 3
2. silkscreen port 2
3. silkscreen port 4
4. silkscreen port 1

Evan

On Tue, 30 May 2006, Milan Kupcevic wrote:

>
> Fabian Knittel wrote:
>
>> In other words: The boards appear to be wired correctly (or maybe just
>> uniformly the wrong way) and the bios, the windows driver and the closed
>> source promise driver (reportedly) know how to handle it.
>> 
>> We have a SATA 150 TX4 board with the same behaviour and would love to
>> see this annoying little bug fixed in linux. :)
>> 
>>  Fabian
>> 
>> Christiaan den Besten wrote:
>> 
>>> We have several of these boards in use [SATA 300 TX4] (bought over time
>>> .. not in one batch). All of them have the ordering as described below.
>>> So another vote for "Please fix!" :)
>>> 
>>> 
>>>> Milan Kupcevic wrote:
>>>> 
>>>> 
>>>>> From: Milan Kupcevic <milan@physics.harvard.edu>
>>>>> 
>>>>> Fix Promise SATAII 150 TX4 (PDC40518) and Promise SATA 300 TX4
>>>>> (PDC40718-GP) wrong port enumeration order that makes it (nearly)
>>>>> impossible to deal with boot problems using two or more drives.
>>>>> 
>>>>> Signed-off-by: Milan Kupcevic <milan@physics.harvard.edu>
>>>>> ---
>>>>> 
>>>>> The current kernel driver assumes:
>>>>> 
>>>>> port 1 - scsi3
>>>>> port 2 - scsi1
>>>>> port 3 - scsi0
>>>>> port 4 - scsi2
>>>>> 
>>>> I totally agree with the fact that the Linux driver gets the ports wrong
>>>> when compared to the BIOS, Windows and surely contradicts the port
>>>> numbers printed on the board. I doubt we all got samples on the one
>>>> bad batch...
>>>> 
>>>> It *is* a real problem and if the solution is correct then I support it.
>>>> 
>>>> Maybe we need a quick feedback from current users: do you guys find
>>>> that the ports are detected as they are labelled (white silk screen)
>>>> on the board or do they show up out of order (as listed above by
>>>> Milan)?
>>>> 
>
> This is a list of Promise SATA TX4 and FastTrak TX4xxx controllers, I have in 
> my lab, affected with the "wiring" bug:
>
> Retail name: SATAII150 TX4
> Chip label: PDC40518  SATAII150
> Vendor-Device number: 105a:3d18 (rev 02)
> Wiring: NEW
>
> Retail name: FastTrak TX4200
> Chip label: PDC40519  RAID  SATAII150
> Vendor-Device number: 105a:3519
> Wiring: NEW
>
> Retail name: SATA300 TX4
> Chip label: PDC40718-GP  SATAII300
> Vendor-Device number: 105a:3d17 (rev 02)
> Wiring: NEW
>
>
> This is the only one Promise TX4 controller, I have in my lab, that is 
> working properly regarding the "wiring" bug with the current kernel driver:
>
> Retail name: FastTrak S150 TX4
> Chip label: PDC20319 RAID SATA 150
> Vendor-Device number: 105a:3319 (rev 02)
> Wiring: OLD
>
>
> This is a list of Promise SATA TX2 and FastTrak TX2xxx controllers, I have in 
> my lab, that are working correctly regarding the "wiring" bug with the 
> current kernel driver:
>
> Retail name: FastTrak S150 TX2plus
> Chip label: PDC20371  SATA 150
> Vendor-Device number: 105a:3371 (rev 02)
>
> Retail name: SATA150 TX2plus
> Chip label: PDC20375  SATA 150
> Vendor-Device number: 105a:3375 (rev 02)
>
> Retail name: FastTrak TX2200
> Chip label: PDC20571  SATAII150
> Vendor-Device number: 105a:3571 (rev 02)
>
>
> It seems the problem exists on all newer Promise SATA TX4 and FastTrak TX4xxx 
> controllers, so I refer to them as the "new wiring" Promise SATA controllers. 
> All the Promise SATA TX2 and FastTrak TX2xxx I have in my lab are working 
> correctly with the current kernel driver, so it seems this "wiring" problem 
> does not affect the TX2(xxx) controllers; only SATA TX4 and FastTrak TX4xxx 
> are affected.
>
> For driver to be able to distinguish the "new wiring" and the "old wiring" 
> Promise TX4(xxx) controllers we need a feedback from the users that are aware 
> of this problem.
>
> Q. How to know if a controller has the "new wiring"? A. You need to be able 
> to boot your testing machine using a hard drive not attached to the 
> controller you are going to test.  Connect 4 different size/brand/model SATA 
> hard drives to the testing controller so you can see the particular order 
> they are recognized by the BIOS and by the kernel (not patched for the "new 
> wiring").   Boot the machine and look for the BIOS recognized hard drive 
> order.  The BIOS recognized hard drive order always matches the order the 
> hard drives are connected to, with respect to port number labels.  If you are 
> testing FastTrak TX series controller you may need to press Ctrl-F (or 
> Ctrl-A) to get into controllers' BIOS and then press "2" to see the BIOS 
> recognized order.  Plain SATA models do not have controller specific BIOS and 
> they will report the BIOS recognized order without user intervention.  You 
> may want to press the "Pause" key on your keyboard to have enough time to 
> read the text on the screen.  If you are arguing with your machine using a 
> serial terminal, there is a Hold Screen button somewhere on the terminal 
> keyboard.   When the machine boots up, type "cat /proc/scsi/scsi", it will 
> show up the order hard drives are recognized by the kernel.  Make sure the 
> kernel you are using is NOT patched for the "new wiring" bug.  If you have 
> the "new wiring" case, the order will be 3-2-4-1; that means, the drive 
> connected to the "port 3" and recognized as the third drive connected to the 
> controller by the BIOS, will be seen by the kernel as first hard drive 
> connected to this controller.  The second drive is always at second place, 
> the fourth one goes at third place and the first one goes at fourth place.
>
>
> Please respond with this data:
>
> - Your Promise SATA controller retail name
> - Chip label (PDCxxxxx)
> - PCI vendor and device code as you can get with "lspci -n"
> - Say if the controler has the new or the old wiring
>
> Your feedback will be appreciated.
>
>
> NOTE: the patch I have submitted ( 
> http://marc.theaimsgroup.com/?l=linux-ide&m=114082978311290&w=2 ) is a 
> solution that doesn't know about the older Promise SATA controllers, which 
> are not affected with the "new wiring" problem, so the older controllers will 
> appear screwed if you use it.
>
> Hopefully we will collect enough info about all the SATA Promise controllers 
> to distinguish the new and the old wiring controllers, then produce a new 
> patch that will be a correct solution to the "new wiring" problem.
>
>
> The best to all,
>
> Milan
>
> -- 
> Milan Kupcevic
> System Administrator
> Harvard University
> Department of Physics
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Jeff Garzik]

Evan Harris wrote:
> 
> I have a card that mirrors this one from your list:
> 
> Retail name: SATA300 TX4
> Chip label: PDC40718-GP  SATAII300
> Vendor-Device number: 105a:3d17 (rev 02)
> 
> Through testing, I've found linux 2.6.16 and 2.6.17 find the ports in 
> this order (the list is ordered by linux detection):
> 
> 1. silkscreen port 3
> 2. silkscreen port 2
> 3. silkscreen port 4
> 4. silkscreen port 1
>> NOTE: the patch I have submitted ( 
>> http://marc.theaimsgroup.com/?l=linux-ide&m=114082978311290&w=2 ) is a 
>> solution that doesn't know about the older Promise SATA controllers, 
>> which are not affected with the "new wiring" problem, so the older 
>> controllers will appear screwed if you use it.
>>
>> Hopefully we will collect enough info about all the SATA Promise 
>> controllers to distinguish the new and the old wiring controllers, 
>> then produce a new patch that will be a correct solution to the "new 
>> wiring" problem.

Mikael Pettersson has been doing some excellent work recently on 
sata_promise.  If enough data has been collected on this sata_promise 
port enumeration problem, maybe the data could be collated and proposed 
via Mikael as a patch?

	Jeff

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Walter Hutchins]

[-- Attachment #1: Type: text/plain, Size: 4004 bytes --]

The first 2 ports on the SATA 300 TX4302 board are wired in reverse of
the SATA 300 TX4 board.
Wrong port order (still) makes it (nearly) impossible to deal with boot
problems using two or more drives for users of TX4302 board.

Driver was modified to remap ports on certain boards according to this line:
        static const unsigned char sataii_tx4_port_remap[4] = { 3, 1, 0, 2};

That modification makes the situation bad for users of TX4302 board.

The situation could be much improved by adding kernel config parameters
allowing users requiring a different remap order some sub options for
CONFIG_SATA_PROMISE which would default to the current remap order.
The sub options would not need to appear except by user kepress
to open sub menu.

config PROMISE_TX4302_REMAP
         prompt "TX4302 port remap"
         ---help---
           The TX4302 card reverses ports 1 and 2 compared to the TX4 card.
           Say Y here if you are using the TX4302 card and you want ata1 to
           correspond to port 1 printed on the card (the first esata port).

           If unsure say N

config PROMISE_TX4_NO_REMAP
         prompt "TX4 no port remap"
         ---help---
           The TX4 and TX4302 cards enumerate the ports in a peculiar order
           compared to the ports numbers printed on the card.

           Say Y here if you want to use the peculiar native port ordering.
           You may want this if you want the ports to resolve the
           same way they did prior to kernel version 2.6.22.
           This would be useful if you sometimes boot older kernels
           or if upgrading numerous machines from kernels older than 2.6.22
           and not wanting to change all the connections.

           If unsure say N

--- a/drivers/ata/sata_promise.c        2009-10-02 13:26:47.000000000 -0400
+++ b/drivers/ata/sata_promise.c        2009-10-02 13:30:20.000000000 -0400
@@ -688,7 +688,15 @@
 static unsigned int pdc_port_no_to_ata_no(unsigned int port_no,
                                          int is_sataii_tx4)
 {
-       static const unsigned char sataii_tx4_port_remap[4] = { 3, 1, 0, 2};
+        #ifdef CONFIG_PROMISE_TX4302_REMAP
+          static const unsigned char sataii_tx4_port_remap[4] = { 1, 3, 0, 2};
+        #else
+          #ifdef CONFIG_PROMISE_TX4_NO_REMAP
+          static const unsigned char sataii_tx4_port_remap[4] = { 0, 1, 2, 3};
+          #else
+          static const unsigned char sataii_tx4_port_remap[4] = { 3, 1, 0, 2};
+          #endif
+        #endif
        return is_sataii_tx4 ? sataii_tx4_port_remap[port_no] : port_no;
 }

Proof that TX4302 is wired differently from TX4 on the first 2 ports:

Retail name: SATA 300 TX4302 2-port eSATA and 2-port internal SATA
Chip label: PDC40718-GP SATAII 300
Vendor-Device number: 105a:3d17 (rev 02)
Wiring: not-New and not-Old
Bios version: 1.00.0.36
----------------------------noremap (vanilla order prior to 2.6.22)-------------
scsi1  ata2  bios0  silkscreen1  model-ST3500641AS  dev/sdb  976773168 NCQ
scsi3  ata4  bios1  silkscreen2  model-WD My Book   dev/sdd  976773168
scsi0  ata1  bios2  silkscreen3  model-WDC WD400BB  dev/sda  78165360
scsi2  ata3  bios3  silkscreen4  model-WDC WD600AB  dev/sdc  117231408
----------------------------remap 3102 (vanilla order since 2.6.22)-------------
scsi1  ata2  bios0  silkscreen1  model-ST3500641AS  dev/sdb  976773168 NCQ
scsi0  ata1  bios1  silkscreen2  model-WD My Book   dev/sda  976773168
scsi2  ata3  bios2  silkscreen3  model-WDC WD400BB  dev/sdc  78165360
scsi3  ata4  bios3  silkscreen4  model-WDC WD600AB  dev/sdd  117231408
----------------------------remap 1302 (custom patch required)------------------
scsi0  ata1  bios0  silkscreen1  model-ST3500641AS  dev/sda  976773168 NCQ
scsi1  ata2  bios1  silkscreen2  model-WD My Book   dev/sdb  976773168
scsi2  ata3  bios2  silkscreen3  model-WDC WD400BB  dev/sdc  78165360
scsi3  ata4  bios3  silkscreen4  model-WDC WD600AB  dev/sdd  117231408

The noremap log and lspci attached.

[-- Attachment #2: noremap-log.txt --]
[-- Type: text/plain, Size: 23421 bytes --]

------------------- noremap log and lspci ----------------------------------
Oct  3 15:33:22 lfs syslogd 1.5.0: restart.
Oct  3 15:33:23 lfs kernel: klogd 1.5.0, log source = /proc/kmsg started.
Oct  3 15:33:23 lfs kernel: Inspecting /boot/System.map-2.6.18.8
Oct  3 15:33:23 lfs kernel: Loaded 28969 symbols from /boot/System.map-2.6.18.8.
Oct  3 15:33:23 lfs kernel: Symbols match kernel version 2.6.18.
Oct  3 15:33:23 lfs kernel: Loaded 292 symbols from 2 modules.
Oct  3 15:33:23 lfs kernel: Linux version 2.6.18.8 (root@lfs) (gcc version 3.3.6) #1 Fri Sep 25 20:25:03 EDT 2009
Oct  3 15:33:23 lfs kernel: BIOS-provided physical RAM map:
Oct  3 15:33:23 lfs kernel:  BIOS-e820: 0000000000000000 - 000000000009d400 (usable)
Oct  3 15:33:23 lfs kernel:  BIOS-e820: 000000000009d400 - 00000000000a0000 (reserved)
Oct  3 15:33:23 lfs kernel:  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Oct  3 15:33:23 lfs kernel:  BIOS-e820: 0000000000100000 - 000000005fffc000 (usable)
Oct  3 15:33:23 lfs kernel:  BIOS-e820: 000000005fffc000 - 000000005ffff000 (ACPI data)
Oct  3 15:33:23 lfs kernel:  BIOS-e820: 000000005ffff000 - 0000000060000000 (ACPI NVS)
Oct  3 15:33:23 lfs kernel:  BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Oct  3 15:33:23 lfs kernel: 639MB HIGHMEM available.
Oct  3 15:33:23 lfs kernel: 896MB LOWMEM available.
Oct  3 15:33:23 lfs kernel: On node 0 totalpages: 393212
Oct  3 15:33:23 lfs kernel:   DMA zone: 4096 pages, LIFO batch:0
Oct  3 15:33:23 lfs kernel:   Normal zone: 225280 pages, LIFO batch:31
Oct  3 15:33:23 lfs kernel:   HighMem zone: 163836 pages, LIFO batch:31
Oct  3 15:33:23 lfs kernel: DMI 2.3 present.
Oct  3 15:33:23 lfs kernel: ACPI: RSDP (v000 ASUS                                  ) @ 0x000f5a60
Oct  3 15:33:23 lfs kernel: ACPI: RSDT (v001 ASUS   P3V_4X   0x30303031 MSFT 0x31313031) @ 0x5fffc000
Oct  3 15:33:23 lfs kernel: ACPI: FADT (v001 ASUS   P3V_4X   0x30303031 MSFT 0x31313031) @ 0x5fffc080
Oct  3 15:33:23 lfs kernel: ACPI: BOOT (v001 ASUS   P3V_4X   0x30303031 MSFT 0x31313031) @ 0x5fffc040
Oct  3 15:33:23 lfs kernel: ACPI: DSDT (v001   ASUS P3V_4X   0x00001000 MSFT 0x0100000b) @ 0x00000000
Oct  3 15:33:23 lfs kernel: ACPI: PM-Timer IO Port: 0xe408
Oct  3 15:33:23 lfs kernel: Allocating PCI resources starting at 70000000 (gap: 60000000:9fff0000)
Oct  3 15:33:23 lfs kernel: Detected 803.063 MHz processor.
Oct  3 15:33:23 lfs kernel: Built 1 zonelists.  Total pages: 393212
Oct  3 15:33:23 lfs kernel: Kernel command line: root=/dev/sdb11 ide0=noprobe
Oct  3 15:33:23 lfs kernel: ide_setup: ide0=noprobe
Oct  3 15:33:23 lfs kernel: Local APIC disabled by BIOS -- you can enable it with "lapic"
Oct  3 15:33:23 lfs kernel: mapped APIC to ffffd000 (01c05000)
Oct  3 15:33:23 lfs kernel: Enabling fast FPU save and restore... done.
Oct  3 15:33:23 lfs kernel: Enabling unmasked SIMD FPU exception support... done.
Oct  3 15:33:23 lfs kernel: Initializing CPU#0
Oct  3 15:33:23 lfs kernel: PID hash table entries: 4096 (order: 12, 16384 bytes)
Oct  3 15:33:23 lfs kernel: Console: colour VGA+ 80x25
Oct  3 15:33:23 lfs kernel: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Oct  3 15:33:23 lfs kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Oct  3 15:33:23 lfs kernel: Memory: 1554452k/1572848k available (2639k kernel code, 17300k reserved, 1115k data, 180k init, 655344k highmem)
Oct  3 15:33:23 lfs kernel: Checking if this processor honours the WP bit even in supervisor mode... Ok.
Oct  3 15:33:23 lfs kernel: Calibrating delay using timer specific routine.. 1606.92 BogoMIPS (lpj=803462)
Oct  3 15:33:23 lfs kernel: Mount-cache hash table entries: 512
Oct  3 15:33:23 lfs kernel: CPU: After generic identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000
Oct  3 15:33:23 lfs kernel: CPU: After vendor identify, caps: 0383f9ff 00000000 00000000 00000000 00000000 00000000 00000000
Oct  3 15:33:23 lfs kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Oct  3 15:33:23 lfs kernel: CPU: L2 cache: 256K
Oct  3 15:33:23 lfs kernel: CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000 00000000 00000000
Oct  3 15:33:23 lfs kernel: Intel machine check architecture supported.
Oct  3 15:33:23 lfs kernel: Intel machine check reporting enabled on CPU#0.
Oct  3 15:33:23 lfs kernel: Compat vDSO mapped to ffffe000.
Oct  3 15:33:23 lfs kernel: CPU: Intel Pentium III (Coppermine) stepping 06
Oct  3 15:33:23 lfs kernel: Checking 'hlt' instruction... OK.
Oct  3 15:33:23 lfs kernel: ACPI: Core revision 20060707
Oct  3 15:33:23 lfs kernel: ACPI: setting ELCR to 0200 (from 0e20)
Oct  3 15:33:23 lfs kernel: NET: Registered protocol family 16
Oct  3 15:33:23 lfs kernel: ACPI: bus type pci registered
Oct  3 15:33:23 lfs kernel: PCI: PCI BIOS revision 2.10 entry at 0xf0890, last bus=1
Oct  3 15:33:23 lfs kernel: PCI: Using configuration type 1
Oct  3 15:33:23 lfs kernel: Setting up standard PCI resources
Oct  3 15:33:23 lfs kernel: ACPI: Interpreter enabled
Oct  3 15:33:23 lfs kernel: ACPI: Using PIC for interrupt routing
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12 14 15)
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 *10 11 12 14 15)
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 *5 6 7 9 10 11 12 14 15)
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12 14 15)
Oct  3 15:33:23 lfs kernel: ACPI: PCI Root Bridge [PCI0] (0000:00)
Oct  3 15:33:23 lfs kernel: PCI: Probing PCI hardware (bus 00)
Oct  3 15:33:23 lfs kernel: ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
Oct  3 15:33:23 lfs kernel: Boot video device is 0000:01:00.0
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
Oct  3 15:33:23 lfs kernel: Linux Plug and Play Support v0.97 (c) Adam Belay
Oct  3 15:33:23 lfs kernel: pnp: PnP ACPI init
Oct  3 15:33:23 lfs kernel: pnp: PnP ACPI: found 14 devices
Oct  3 15:33:23 lfs kernel: SCSI subsystem initialized
Oct  3 15:33:23 lfs kernel: usbcore: registered new driver usbfs
Oct  3 15:33:23 lfs kernel: usbcore: registered new driver hub
Oct  3 15:33:23 lfs kernel: PCI: Using ACPI for IRQ routing
Oct  3 15:33:23 lfs kernel: PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
Oct  3 15:33:23 lfs kernel: pnp: 00:03: ioport range 0xe400-0xe47f could not be reserved
Oct  3 15:33:23 lfs kernel: pnp: 00:03: ioport range 0xe800-0xe80f has been reserved
Oct  3 15:33:23 lfs kernel: PCI: Bridge: 0000:00:01.0
Oct  3 15:33:23 lfs kernel:   IO window: disabled.
Oct  3 15:33:23 lfs kernel:   MEM window: d6000000-d7dfffff
Oct  3 15:33:23 lfs kernel:   PREFETCH window: d7f00000-e3ffffff
Oct  3 15:33:23 lfs kernel: PCI: Setting latency timer of device 0000:00:01.0 to 64
Oct  3 15:33:23 lfs kernel: NET: Registered protocol family 2
Oct  3 15:33:23 lfs kernel: IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
Oct  3 15:33:23 lfs kernel: TCP established hash table entries: 131072 (order: 7, 524288 bytes)
Oct  3 15:33:23 lfs kernel: TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
Oct  3 15:33:23 lfs kernel: TCP: Hash tables configured (established 131072 bind 65536)
Oct  3 15:33:23 lfs kernel: TCP reno registered
Oct  3 15:33:23 lfs kernel: Simple Boot Flag at 0x3a set to 0x1
Oct  3 15:33:23 lfs kernel: Machine check exception polling timer started.
Oct  3 15:33:23 lfs kernel: highmem bounce pool size: 64 pages
Oct  3 15:33:23 lfs kernel: Initializing Cryptographic API
Oct  3 15:33:23 lfs kernel: io scheduler noop registered
Oct  3 15:33:23 lfs kernel: io scheduler cfq registered (default)
Oct  3 15:33:23 lfs kernel: Activating ISA DMA hang workarounds.
Oct  3 15:33:23 lfs kernel: lp: driver loaded but no devices found
Oct  3 15:33:23 lfs kernel: Real Time Clock Driver v1.12ac
Oct  3 15:33:23 lfs kernel: Non-volatile memory driver v1.2
Oct  3 15:33:23 lfs kernel: Linux agpgart interface v0.101 (c) Dave Jones
Oct  3 15:33:23 lfs kernel: agpgart: Detected VIA Apollo Pro 133 chipset
Oct  3 15:33:23 lfs kernel: agpgart: AGP aperture is 64M @ 0xe4000000
Oct  3 15:33:23 lfs kernel: [drm] Initialized drm 1.0.1 20051102
Oct  3 15:33:23 lfs kernel: Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
Oct  3 15:33:23 lfs kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Oct  3 15:33:23 lfs kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Oct  3 15:33:23 lfs kernel: 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
Oct  3 15:33:23 lfs kernel: 00:0b: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Oct  3 15:33:23 lfs kernel: parport: PnPBIOS parport detected.
Oct  3 15:33:23 lfs kernel: parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP]
Oct  3 15:33:23 lfs kernel: lp0: using parport0 (interrupt-driven).
Oct  3 15:33:23 lfs kernel: Floppy drive(s): fd0 is 1.44M
Oct  3 15:33:23 lfs kernel: FDC 0 is a post-1991 82077
Oct  3 15:33:23 lfs kernel: loop: loaded (max 8 devices)
Oct  3 15:33:23 lfs kernel: e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
Oct  3 15:33:23 lfs kernel: e100: Copyright(c) 1999-2005 Intel Corporation
Oct  3 15:33:23 lfs kernel: Linux Tulip driver version 1.1.13 (May 11, 2002)
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 9
Oct  3 15:33:23 lfs kernel: PCI: setting IRQ 9 as level-triggered
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
Oct  3 15:33:23 lfs kernel: tulip0:  MII transceiver #1 config 1000 status 786d advertising 01e1.
Oct  3 15:33:23 lfs kernel: eth0: ADMtek Comet rev 17 at 0001d000, 00:03:6D:14:18:92, IRQ 9.
Oct  3 15:33:23 lfs kernel: Linux video capture interface: v2.00
Oct  3 15:33:23 lfs kernel: saa7130/34: v4l2 driver version 0.2.14 loaded
Oct  3 15:33:23 lfs kernel: Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
Oct  3 15:33:23 lfs kernel: ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
Oct  3 15:33:23 lfs kernel: VP_IDE: IDE controller at PCI slot 0000:00:04.1
Oct  3 15:33:23 lfs kernel: VP_IDE: chipset revision 6
Oct  3 15:33:23 lfs kernel: VP_IDE: not 100% native mode: will probe irqs later
Oct  3 15:33:23 lfs kernel: VP_IDE: VIA vt82c596b (rev 12) IDE UDMA66 controller on pci0000:00:04.1
Oct  3 15:33:23 lfs kernel:     ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:pio, hdb:pio
Oct  3 15:33:23 lfs kernel:     ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
Oct  3 15:33:23 lfs kernel: Probing IDE interface ide1...
Oct  3 15:33:23 lfs kernel: hdc: CREATIVE DVD-ROM DVD1243E, ATAPI CD/DVD-ROM drive
Oct  3 15:33:23 lfs kernel: hdd: LITE-ON LTR-52246S, ATAPI CD/DVD-ROM drive
Oct  3 15:33:23 lfs kernel: ide1 at 0x170-0x177,0x376 on irq 15
Oct  3 15:33:23 lfs kernel: PDC20268: IDE controller at PCI slot 0000:00:0c.0
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
Oct  3 15:33:23 lfs kernel: PCI: setting IRQ 11 as level-triggered
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt 0000:00:0c.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
Oct  3 15:33:23 lfs kernel: PDC20268: chipset revision 2
Oct  3 15:33:23 lfs kernel: PDC20268: ROM enabled at 0x70028000
Oct  3 15:33:23 lfs kernel: PDC20268: 100% native mode on irq 11
Oct  3 15:33:23 lfs kernel:     ide2: BM-DMA at 0xa000-0xa007, BIOS settings: hde:pio, hdf:pio
Oct  3 15:33:23 lfs kernel:     ide3: BM-DMA at 0xa008-0xa00f, BIOS settings: hdg:pio, hdh:pio
Oct  3 15:33:23 lfs kernel: Probing IDE interface ide2...
Oct  3 15:33:23 lfs kernel: Probing IDE interface ide3...
Oct  3 15:33:23 lfs kernel: hdc: ATAPI 40X DVD-ROM drive, 512kB Cache
Oct  3 15:33:23 lfs kernel: Uniform CD-ROM driver Revision: 3.20
Oct  3 15:33:23 lfs kernel: hdd: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache
Oct  3 15:33:23 lfs kernel: libata version 2.00 loaded.
Oct  3 15:33:23 lfs kernel: sata_promise 0000:00:0e.0: version 1.04
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 5
Oct  3 15:33:23 lfs kernel: PCI: setting IRQ 5 as level-triggered
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LNKC] -> GSI 5 (level, low) -> IRQ 5
Oct  3 15:33:23 lfs kernel: ata1: SATA max UDMA/133 cmd 0xF881C200 ctl 0xF881C238 bmdma 0x0 irq 5
Oct  3 15:33:23 lfs kernel: ata2: SATA max UDMA/133 cmd 0xF881C280 ctl 0xF881C2B8 bmdma 0x0 irq 5
Oct  3 15:33:23 lfs kernel: ata3: SATA max UDMA/133 cmd 0xF881C300 ctl 0xF881C338 bmdma 0x0 irq 5
Oct  3 15:33:23 lfs kernel: ata4: SATA max UDMA/133 cmd 0xF881C380 ctl 0xF881C3B8 bmdma 0x0 irq 5
Oct  3 15:33:23 lfs kernel: scsi0 : sata_promise
Oct  3 15:33:23 lfs kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct  3 15:33:23 lfs kernel: ata1.00: ATA-5, max UDMA/100, 78165360 sectors: LBA 
Oct  3 15:33:23 lfs kernel: ata1.00: ata1: dev 0 multi count 0
Oct  3 15:33:23 lfs kernel: ata1.00: applying bridge limits
Oct  3 15:33:23 lfs kernel: ata1.00: configured for UDMA/100
Oct  3 15:33:23 lfs kernel: scsi1 : sata_promise
Oct  3 15:33:23 lfs kernel: ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct  3 15:33:23 lfs kernel: ata2.00: ATA-7, max UDMA/133, 976773168 sectors: LBA48 NCQ (depth 0/32)
Oct  3 15:33:23 lfs kernel: ata2.00: configured for UDMA/133
Oct  3 15:33:23 lfs kernel: scsi2 : sata_promise
Oct  3 15:33:23 lfs kernel: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct  3 15:33:23 lfs kernel: ata3.00: ATA-5, max UDMA/100, 117231408 sectors: LBA 
Oct  3 15:33:23 lfs kernel: ata3.00: ata3: dev 0 multi count 0
Oct  3 15:33:23 lfs kernel: ata3.00: applying bridge limits
Oct  3 15:33:23 lfs kernel: ata3.00: configured for UDMA/100
Oct  3 15:33:23 lfs kernel: scsi3 : sata_promise
Oct  3 15:33:23 lfs kernel: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct  3 15:33:23 lfs kernel: ata4.00: ATA-6, max UDMA/133, 976773168 sectors: LBA48 
Oct  3 15:33:23 lfs kernel: ata4.00: ata4: dev 0 multi count 0
Oct  3 15:33:23 lfs kernel: ata4.00: configured for UDMA/133
Oct  3 15:33:23 lfs kernel:   Vendor: ATA       Model: WDC WD400BB-00DG  Rev: 05.0
Oct  3 15:33:23 lfs kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05
Oct  3 15:33:23 lfs kernel:   Vendor: ATA       Model: ST3500641AS       Rev: 3.AA
Oct  3 15:33:23 lfs kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05
Oct  3 15:33:23 lfs kernel:   Vendor: ATA       Model: WDC WD600AB-32BV  Rev: 21.0
Oct  3 15:33:23 lfs kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05
Oct  3 15:33:23 lfs kernel:   Vendor: ATA       Model: WD      My Book   Rev: 012 
Oct  3 15:33:23 lfs kernel:   Type:   Direct-Access                      ANSI SCSI revision: 05
Oct  3 15:33:23 lfs kernel: SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
Oct  3 15:33:23 lfs kernel: sda: Write Protect is off
Oct  3 15:33:23 lfs kernel: sda: Mode Sense: 00 3a 00 00
Oct  3 15:33:23 lfs kernel: SCSI device sda: drive cache: write back
Oct  3 15:33:23 lfs kernel: SCSI device sda: 78165360 512-byte hdwr sectors (40021 MB)
Oct  3 15:33:23 lfs kernel: sda: Write Protect is off
Oct  3 15:33:23 lfs kernel: sda: Mode Sense: 00 3a 00 00
Oct  3 15:33:23 lfs kernel: SCSI device sda: drive cache: write back
Oct  3 15:33:23 lfs kernel:  sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 >
Oct  3 15:33:23 lfs kernel: sd 0:0:0:0: Attached scsi disk sda
Oct  3 15:33:23 lfs kernel: SCSI device sdb: 976773168 512-byte hdwr sectors (500108 MB)
Oct  3 15:33:23 lfs kernel: sdb: Write Protect is off
Oct  3 15:33:23 lfs kernel: sdb: Mode Sense: 00 3a 00 00
Oct  3 15:33:23 lfs kernel: SCSI device sdb: drive cache: write back
Oct  3 15:33:23 lfs kernel: SCSI device sdb: 976773168 512-byte hdwr sectors (500108 MB)
Oct  3 15:33:23 lfs kernel: sdb: Write Protect is off
Oct  3 15:33:23 lfs kernel: sdb: Mode Sense: 00 3a 00 00
Oct  3 15:33:23 lfs kernel: SCSI device sdb: drive cache: write back
Oct  3 15:33:23 lfs kernel:  sdb: sdb1 sdb2 < sdb5 sdb6 sdb7 sdb8 sdb9 sdb10 sdb11 sdb12 sdb13 sdb14 sdb15 > sdb3
Oct  3 15:33:23 lfs kernel: sd 1:0:0:0: Attached scsi disk sdb
Oct  3 15:33:23 lfs kernel: SCSI device sdc: 117231408 512-byte hdwr sectors (60022 MB)
Oct  3 15:33:23 lfs kernel: sdc: Write Protect is off
Oct  3 15:33:23 lfs kernel: sdc: Mode Sense: 00 3a 00 00
Oct  3 15:33:23 lfs kernel: SCSI device sdc: drive cache: write back
Oct  3 15:33:23 lfs kernel: SCSI device sdc: 117231408 512-byte hdwr sectors (60022 MB)
Oct  3 15:33:23 lfs kernel: sdc: Write Protect is off
Oct  3 15:33:23 lfs kernel: sdc: Mode Sense: 00 3a 00 00
Oct  3 15:33:23 lfs kernel: SCSI device sdc: drive cache: write back
Oct  3 15:33:23 lfs kernel:  sdc: sdc1 sdc2 < sdc5 sdc6 sdc7 sdc8 sdc9 sdc10 > sdc3
Oct  3 15:33:23 lfs kernel: sd 2:0:0:0: Attached scsi disk sdc
Oct  3 15:33:23 lfs kernel: SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB)
Oct  3 15:33:23 lfs kernel: sdd: Write Protect is off
Oct  3 15:33:23 lfs kernel: sdd: Mode Sense: 00 3a 00 00
Oct  3 15:33:23 lfs kernel: SCSI device sdd: drive cache: write back
Oct  3 15:33:23 lfs kernel: SCSI device sdd: 976773168 512-byte hdwr sectors (500108 MB)
Oct  3 15:33:23 lfs kernel: sdd: Write Protect is off
Oct  3 15:33:23 lfs kernel: sdd: Mode Sense: 00 3a 00 00
Oct  3 15:33:23 lfs kernel: SCSI device sdd: drive cache: write back
Oct  3 15:33:23 lfs kernel:  sdd: sdd1 sdd2 < sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 > sdd3 sdd4
Oct  3 15:33:23 lfs kernel: sd 3:0:0:0: Attached scsi disk sdd
Oct  3 15:33:23 lfs kernel: USB Universal Host Controller Interface driver v3.0
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt 0000:00:04.2[D] -> Link [LNKD] -> GSI 9 (level, low) -> IRQ 9
Oct  3 15:33:23 lfs kernel: uhci_hcd 0000:00:04.2: UHCI Host Controller
Oct  3 15:33:23 lfs kernel: uhci_hcd 0000:00:04.2: new USB bus registered, assigned bus number 1
Oct  3 15:33:23 lfs kernel: uhci_hcd 0000:00:04.2: irq 9, io base 0x0000d400
Oct  3 15:33:23 lfs kernel: usb usb1: configuration #1 chosen from 1 choice
Oct  3 15:33:23 lfs kernel: hub 1-0:1.0: USB hub found
Oct  3 15:33:23 lfs kernel: hub 1-0:1.0: 2 ports detected
Oct  3 15:33:23 lfs kernel: Initializing USB Mass Storage driver...
Oct  3 15:33:23 lfs kernel: usb 1-1: new full speed USB device using uhci_hcd and address 2
Oct  3 15:33:23 lfs kernel: usb 1-1: configuration #1 chosen from 1 choice
Oct  3 15:33:23 lfs kernel: usbcore: registered new driver usb-storage
Oct  3 15:33:23 lfs kernel: USB Mass Storage support registered.
Oct  3 15:33:23 lfs kernel: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
Oct  3 15:33:23 lfs kernel: serio: i8042 AUX port at 0x60,0x64 irq 12
Oct  3 15:33:23 lfs kernel: serio: i8042 KBD port at 0x60,0x64 irq 1
Oct  3 15:33:23 lfs kernel: mice: PS/2 mouse device common for all mice
Oct  3 15:33:23 lfs kernel: input: PC Speaker as /class/input/input0
Oct  3 15:33:23 lfs kernel: input: AT Translated Set 2 keyboard as /class/input/input1
Oct  3 15:33:23 lfs kernel: i2c /dev entries driver
Oct  3 15:33:23 lfs kernel: Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
Oct  3 15:33:23 lfs kernel: ALSA device list:
Oct  3 15:33:23 lfs kernel:   No soundcards found.
Oct  3 15:33:23 lfs kernel: TCP bic registered
Oct  3 15:33:23 lfs kernel: NET: Registered protocol family 1
Oct  3 15:33:23 lfs kernel: NET: Registered protocol family 17
Oct  3 15:33:23 lfs kernel: Using IPI Shortcut mode
Oct  3 15:33:23 lfs kernel: ACPI: (supports S0 S1<6>Time: tsc clocksource has been installed.
Oct  3 15:33:23 lfs kernel:  S4 S5)
Oct  3 15:33:23 lfs kernel: kjournald starting.  Commit interval 5 seconds
Oct  3 15:33:23 lfs kernel: EXT3-fs: mounted filesystem with ordered data mode.
Oct  3 15:33:23 lfs kernel: VFS: Mounted root (ext3 filesystem) readonly.
Oct  3 15:33:23 lfs kernel: Freeing unused kernel memory: 180k freed
Oct  3 15:33:23 lfs kernel: input: ImPS/2 Generic Wheel Mouse as /class/input/input2
Oct  3 15:33:23 lfs kernel: udev: starting version 130
Oct  3 15:33:23 lfs kernel: udev: deprecated sysfs layout (kernel too old, or CONFIG_SYSFS_DEPRECATED) is unsupported, some udev features may fail
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 10
Oct  3 15:33:23 lfs kernel: PCI: setting IRQ 10 as level-triggered
Oct  3 15:33:23 lfs kernel: ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKB] -> GSI 10 (level, low) -> IRQ 10
Oct  3 15:33:23 lfs kernel: drivers/usb/class/usblp.c: usblp0: USB Bidirectional printer dev 2 if 0 alt 0 proto 2 vid 0x03F0 pid 0x7004
Oct  3 15:33:23 lfs kernel: usbcore: registered new driver usblp
Oct  3 15:33:23 lfs kernel: drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Oct  3 15:33:23 lfs kernel: Adding 522072k swap on /dev/sdb6.  Priority:1 extents:1 across:522072k
Oct  3 15:33:23 lfs kernel: EXT3 FS on sdb11, internal journal
Oct  3 15:33:23 lfs dhcpcd[2010]: eth0: dhcpcd 4.0.7 starting
Oct  3 15:33:23 lfs dhcpcd[2010]: eth0: broadcasting for a lease
Oct  3 15:33:24 lfs dhcpcd[2010]: eth0: offered 192.168.1.96 from 192.168.1.254
Oct  3 15:33:24 lfs dhcpcd[2010]: eth0: checking 192.168.1.96 is available on attached networks
Oct  3 15:33:26 lfs kernel: 0000:00:09.0: tulip_stop_rxtx() failed
Oct  3 15:33:26 lfs kernel: eth0: Setting full-duplex based on MII#1 link partner capability of 41e1.
Oct  3 15:33:29 lfs dhcpcd[2010]: eth0: acknowledged 192.168.1.96 from 192.168.1.254
Oct  3 15:33:29 lfs dhcpcd[2010]: eth0: leased 192.168.1.96 for 86400 seconds

Relevant portion of lspci -vvvxxx:
00:0e.0 Mass storage controller: Promise Technology, Inc. PDC40718 (SATA 300 TX4) (rev 02)
        Subsystem: Promise Technology, Inc. PDC40718 (SATA 300 TX4)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 88 (1000ns min, 4500ns max), Cache Line Size: 4 bytes
        Interrupt: pin A routed to IRQ 5
        Region 0: I/O ports at 9000 [size=128]
        Region 2: I/O ports at 8800 [size=256]
        Region 3: Memory at d3800000 (32-bit, non-prefetchable) [size=4K]
        Region 4: Memory at d3000000 (32-bit, non-prefetchable) [size=128K]
        [virtual] Expansion ROM at 60020000 [disabled] [size=32K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 5a 10 17 3d 17 00 30 02 02 00 80 01 01 58 00 00
10: 01 90 00 00 00 00 00 00 01 88 00 00 00 00 80 d3
20: 00 00 00 d3 00 00 00 00 00 00 00 00 5a 10 17 3d
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 04 12
40: 00 00 05 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 00 22 02 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 04 ff ff 03 00 00 00 00 00 00 00 00 00

Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4

[Mikael Pettersson]

Walter Hutchins writes:
 > The first 2 ports on the SATA 300 TX4302 board are wired in reverse of
 > the SATA 300 TX4 board.
 > Wrong port order (still) makes it (nearly) impossible to deal with boot
 > problems using two or more drives for users of TX4302 board.
 > 
 > Driver was modified to remap ports on certain boards according to this line:
 >         static const unsigned char sataii_tx4_port_remap[4] = { 3, 1, 0, 2};
 > 
 > That modification makes the situation bad for users of TX4302 board.
 > 
 > The situation could be much improved by adding kernel config parameters
 > allowing users requiring a different remap order some sub options for
 > CONFIG_SATA_PROMISE which would default to the current remap order.

Compile-time config options for special cases aren't going to fly.
No distro is going to enable them, which means that those that need
them have to build their own kernels, by which time they could just
apply some well-known tx4302 patch.

Better would be a module option sata_promise.tx4remap=0/1/2, with
0 meaning no remap, 1 remap for 300tx4 like now, and 2 remap for
the tx4302. This should be easy to implement.

Even better would be an option saying "do $REMAP for PCI device
AA:BB:C", as that would allow a system to have a mix of 300tx4
and tx4302 cards. But it might not be easy to implement.

(A reminder to linux-ide: Promise first did a really bogus change
to the internal-to-external port numbering in their 2nd generation
4-port cards. Then they reused the same chip for the TX4302 and
changed the internal-to-external port numbering again, with no
way for the driver to detect this since the PCI IDs are the same.)