sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4
PATCH 1/1 sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4
From: Milan Kupcevic <[email protected]>
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.
---
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(-)
linux/drivers/scsi/sata_promise.c 2006-02-24 19:35:16.000000000 -0500 renamed from drivers/scsi/sata_promise.c 2006-02-17 17:23:45.000000000 -0500 +10 -6
@@ -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;
Signature · 4 lines
Milan Kupcevic System Administrator Harvard University Department of Physics
Quoted 5 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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 <[email protected]>
Quoted 8 lines
---
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
Quoted 17 lines · Jeff Garzik
Quoted 5 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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 <[email protected]>Quoted 8 lines
---
The current kernel driver assumes:
port 1 - scsi3
port 2 - scsi1
port 3 - scsi0
port 4 - scsi2
Quoted 6 lines
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
Signature · 4 lines
Milan Kupcevic System Administrator Harvard University Department of Physics
Quoted 7 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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 <[email protected]>
Quoted 8 lines
---
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)?
Signature · 2 lines
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/> attach .zip as .dat
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" <[email protected]>
To: "Milan Kupcevic" <[email protected]>
Cc: "Jeff Garzik" <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>
Sent: Saturday, February 25, 2006 7:59 AM
Subject: Re: [PATCH] sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4
Quoted 40 lines
Quoted 7 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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 <[email protected]>Quoted 8 lines
---
The current kernel driver assumes:
port 1 - scsi3
port 2 - scsi1
port 3 - scsi0
port 4 - scsi2I 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)?
Signature · 7 lines
Eyal Lebedinsky ([email protected]) <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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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.) ]
Quoted 44 lines · Christiaan den Besten
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" <[email protected]>
To: "Milan Kupcevic" <[email protected]>
Cc: "Jeff Garzik" <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>; <[email protected]>
Sent: Saturday, February 25, 2006 7:59 AM
Subject: Re: [PATCH]sata_promise: Port enumeration order - SATA 150 TX4, SATA 300 TX4Quoted 30 lines
Quoted 7 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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 <[email protected]>Quoted 8 lines
---
The current kernel driver assumes:
port 1 - scsi3
port 2 - scsi1
port 3 - scsi0
port 4 - scsi2I 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)?
Signature · 2 lines
avona media GbR | Neureuter Str. 5-7 | D-76185 Karlsruhe fon +49 721 53169901 | fax +49 721 53169904 | www.avona.com
Quoted 4 lines · Fabian Knittel
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.
Quoted 48 lines
We have a SATA 150 TX4 board with the same behaviour and would love to see this annoying little bug fixed in linux. :)
Fabian
Quoted 40 lines · Christiaan den Besten
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!" :)
Quoted 34 lines
Quoted 7 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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 <[email protected]>Quoted 10 lines
---
The current kernel driver assumes:
port 1 - scsi3
port 2 - scsi1
port 3 - scsi0
port 4 - scsi2I 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
Signature · 4 lines
Milan Kupcevic System Administrator Harvard University Department of Physics
Quoted 6 lines · Milan Kupcevic
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
Signature · 2 lines
avona media GbR | Neureuter Str. 5-7 | D-76185 Karlsruhe fon +49 721 53169901 | fax +49 721 53169904 | www.avona.com
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
Quoted 130 lines · Milan Kupcevic
Quoted 4 lines · Fabian Knittel
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.
Quoted 43 lines
We have a SATA 150 TX4 board with the same behaviour and would love to see this annoying little bug fixed in linux. :)
Fabian
Quoted 36 lines · Christiaan den Besten
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!" :)
Quoted 31 lines
Quoted 7 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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 <[email protected]>Quoted 9 lines
---
The current kernel driver assumes:
port 1 - scsi3
port 2 - scsi1
port 3 - scsi0
port 4 - scsi2I 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: NEWRetail name: FastTrak TX4200
Chip label: PDC40519 RAID SATAII150
Vendor-Device number: 105a:3519
Wiring: NEWRetail name: SATA300 TX4
Chip label: PDC40718-GP SATAII300
Vendor-Device number: 105a:3d17 (rev 02)
Wiring: NEWThis 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: OLDThis 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 wiringYour 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
Signature · 10 lines
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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · 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)
Quoted 9 lines
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 1Quoted 3 lines
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
Hi,
Quoted 3 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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?
Hi,
Quoted 3 lines · Milan Kupcevic
From: Milan Kupcevic <[email protected]>
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