RE: About forcing 32bit DMA patch for AMD690G(SB600)
Shane Huang [EMAIL PROTECTED] wrote: Dear Tejun: My 5 cents: Just order the board. These stock PC hardware are too cheap these days, it doesn't make any sense to try to debug somewhat difficult problem remotely if the hardware is available on the market. Even if you have to spend your own money, it will be money well spent compared to the time and effort you'll have to spend in comparison - hardware is just too cheap. Yes you are right, we are trying to get one ASUS M2A-VM board. Sorry folks I've been offline for a few weeks I notice I missed out a lot of important emails. Now that I see I need to verify certain things, I'm very happy to do it. Just give me a day or two. Thanks Shane Thanks Srihari Get the name you always wanted with the new y7mail email address. www.yahoo7.com.au/y7mail - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Shane Huang wrote: As Tejun mentioned, the test result on my SB600 engineering board (RS690 A12 +SB600 A21) is a little different from the result of Srihari. But I do not have other SB600 boards especially ASUS M2A-VM to do further debug. So if you can provide us your test result, that's really good. My 5 cents: Just order the board. These stock PC hardware are too cheap these days, it doesn't make any sense to try to debug somewhat difficult problem remotely if the hardware is available on the market. Even if you have to spend your own money, it will be money well spent compared to the time and effort you'll have to spend in comparison - hardware is just too cheap. Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: About forcing 32bit DMA patch for AMD690G(SB600)
Dear Tejun: My 5 cents: Just order the board. These stock PC hardware are too cheap these days, it doesn't make any sense to try to debug somewhat difficult problem remotely if the hardware is available on the market. Even if you have to spend your own money, it will be money well spent compared to the time and effort you'll have to spend in comparison - hardware is just too cheap. Yes you are right, we are trying to get one ASUS M2A-VM board. Thanks Shane - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: About forcing 32bit DMA patch for AMD690G(SB600)
Hi Andrew: Thanks for your help on your platform. And Is there any update at your side on SB600 64bit DMA capacity? As Tejun mentioned, the test result on my SB600 engineering board (RS690 A12 +SB600 A21) is a little different from the result of Srihari. But I do not have other SB600 boards especially ASUS M2A-VM to do further debug. So if you can provide us your test result, that's really good. Thanks Shane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Paprocki Sent: Saturday, January 26, 2008 9:08 AM To: Tejun Heo Cc: Shane Huang; [EMAIL PROTECTED]; linux-ide@vger.kernel.org Subject: Re: About forcing 32bit DMA patch for AMD690G(SB600) I'll try to get that configuration together.. right now I only have 2 1gb sticks installed on the board, so I would need to track down 2gb ones. If I can find some laying around, I'll let you know. Thanks, -Andrew On Jan 25, 2008 12:50 AM, Tejun Heo [EMAIL PROTECTED] wrote: Andrew Paprocki wrote: I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: About forcing 32bit DMA patch for AMD690G(SB600)
Dear Tejun: The test results point to varied kinds and degrees of problems. At the moment. To avoid turning off anything fancy on systems involving SB600/700, we definitely need more info. Shane, can you please summarize chipset product lines and revisions and how they're configured together (e.g. SB600 Axx goes together with RSxxx kind of stuff)? I'll have to ask for other guys' help to summarize them, and will provide it here once I get it. Currently the following issues have been discovered and we need to find out what's caused by which. .. .. * Shane's test with RS690 + SB600 triggered a weird SERR_INTERNAL error condition if pci=nomsi is used insted of quirk_disable_all_msi. This is super-weird. Maybe difference in memory layout and 64bit DMA acutally didn't work? Shane, can you please do some data write/read/verify test on the setup? I will do further debug on these issues before long, because I'm busy with other issues and my SB600 board is being used by other guy.. :-( Thanks Shane - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Konstantin A. Lepikhov wrote: Hi Tejun! Friday 25, at 02:50:06 PM you wrote: Andrew Paprocki wrote: I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? $ lspci -nn 00:00.0 Host bridge [0600]: ATI Technologies Inc RD580 [CrossFire Xpress 3200] Chipset Host Bridge [1002:5952] 00:02.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI-X Root Port [1002:5a34] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] ... Is this hardware enough for testing? I can add 2G to existing 4G of RAM and post dmesg. greater than 4G would be a highly useful configuration... Jeff - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Hello, Konstantin. Konstantin A. Lepikhov wrote: $ lspci -nn 00:00.0 Host bridge [0600]: ATI Technologies Inc RD580 [CrossFire Xpress 3200] Chipset Host Bridge [1002:5952] 00:02.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI-X Root Port [1002:5a34] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] ... Is this hardware enough for testing? I can add 2G to existing 4G of RAM and post dmesg. Srihari's system which couldn't do 64bit DMA was ASUS M2A-VM. I'm including the result of lspci below. Shane verified 64bit works on a configuration which has SB600 and different bridge, RS690, but Shane's test result wasn't perfect either. AHCI triggers SERR_INTERNAL if quirk_disable_all_msi is not used. quirk_disable_all_msi removes the problem but specifying pci=nomsi doesn't. It's unknown whether the difference between Srihari's and Shane's is on the AHCI controller itself (different revisions?) or stemming from the differences in the rest of the system (host/pci bridges). The test results point to varied kinds and degrees of problems. At the moment. To avoid turning off anything fancy on systems involving SB600/700, we definitely need more info. Shane, can you please summarize chipset product lines and revisions and how they're configured together (e.g. SB600 Axx goes together with RSxxx kind of stuff)? Currently the following issues have been discovered and we need to find out what's caused by which. * MSI doesn't work at all. Possibly host or PCI bridge issue. Should be worked around by quirk_disable_all_msi. Shane has verified some systems do have this problem. It's still not clear which configurations have the problem and in such configurations which part. Currently quirk is applied if the system contains RS400_200 or RS480 (these are host bridges, right?). * Disabling INTx disables MSI too. Should be worked around with quirk_msi_intx_disable_bug. This one seems to be mostly taken care of. New revs of SB700 and all SB800s will have this fixed and Shane recently submitted patch to apply quirk to only affected machines. Let's wait and see if anything blows. * 64bit DMA doesn't work. Should be worked around by adding AHCI_HFLAG_32BIT_ONLY in ahci driver. Srihari's system showed failures firmly pointing to this problem. Shane tested different system with SB600 and 64bit DMA itself seemed to work although there were some issues. As written above, it's unclear what causes the difference. * Shane's test with RS690 + SB600 triggered a weird SERR_INTERNAL error condition if pci=nomsi is used insted of quirk_disable_all_msi. This is super-weird. Maybe difference in memory layout and 64bit DMA acutally didn't work? Shane, can you please do some data write/read/verify test on the setup? Thanks. -[:00]-+-00.0 ATI Technologies Inc Unknown device [1002:7910] +-02.0-[:01]--+-00.0 ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] [1002:5b60] | \-00.1 ATI Technologies Inc RV370 [Radeon X300SE] [1002:5b70] +-07.0-[:02]00.0 Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] +-12.0 ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] +-13.0 ATI Technologies Inc SB600 USB (OHCI0) [1002:4387] +-13.1 ATI Technologies Inc SB600 USB (OHCI1) [1002:4388] +-13.2 ATI Technologies Inc SB600 USB (OHCI2) [1002:4389] +-13.3 ATI Technologies Inc SB600 USB (OHCI3) [1002:438a] +-13.4 ATI Technologies Inc SB600 USB (OHCI4) [1002:438b] +-13.5 ATI Technologies Inc SB600 USB Controller (EHCI) [1002:4386] +-14.0 ATI Technologies Inc SB600 SMBus [1002:4385] +-14.1 ATI Technologies Inc SB600 IDE [1002:438c] +-14.2 ATI Technologies Inc SB600 Azalia [1002:4383] +-14.3 ATI Technologies Inc SB600 PCI to LPC Bridge [1002:438d] +-14.4-[:03]-- +-18.0 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] +-18.1 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] +-18.2 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] \-18.3 Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE (prog-if 82 [Master PriP]) Subsystem: ASUSTeK Computer Inc. Unknown device 81ef Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- TAbort - MAbort- SERR- PERR- Latency: 64 Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at 01f0
Re: About forcing 32bit DMA patch for AMD690G(SB600)
I'll try to get that configuration together.. right now I only have 2 1gb sticks installed on the board, so I would need to track down 2gb ones. If I can find some laying around, I'll let you know. Thanks, -Andrew On Jan 25, 2008 12:50 AM, Tejun Heo [EMAIL PROTECTED] wrote: Andrew Paprocki wrote: I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Hi Tejun! Friday 25, at 02:50:06 PM you wrote: Andrew Paprocki wrote: I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? $ lspci -nn 00:00.0 Host bridge [0600]: ATI Technologies Inc RD580 [CrossFire Xpress 3200] Chipset Host Bridge [1002:5952] 00:02.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI-X Root Port [1002:5a34] 00:05.0 PCI bridge [0604]: ATI Technologies Inc RS480 PCI Bridge [1002:5a37] 00:12.0 SATA controller [0106]: ATI Technologies Inc SB600 Non-Raid-5 SATA [1002:4380] ... Is this hardware enough for testing? I can add 2G to existing 4G of RAM and post dmesg. -- WBR et al. - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Hello, Shane. Sorry about the delay. Got caught up in other stuff. Shane Huang wrote: Quoting Tejun: Uh-oh, wait a bit. Nope. Until we figure out what the something else is and positively verify 64bit DMA works fine, the quirk stays in. Our HW engineer has confirmed that our SB600 SATA controller indeed has some MSI issue, and we do not have any workaround. The workaround quirk_msi_intx_disable_bug to SB700 SATA controller can NOT work to SB600 SATA controller in my debug, while disablement to RS690 MSI in kernel source can fix it. Hmmm... Okay. Is the SB600 SATA controller culprit or the north bridge - RS690? If the former is the case, proper way to work around it is to add AHCI_HFLAG_NO_MSI for SB600 AHCI. As to the SB600 64 bit DMA capacity, do you have any methods to do further verification? I do NOT find any problem in my debug after I disabled RS690 MSI in kernel 2.6.24-rc7. The problem is that we didn't actually prove anything. In the tests you've done, pci=nomsi didn't fix the problem but disable_all_msi quirk did. pci=nomsi and disable_all_msi quirk are identical. Also, Srihari's problem was not reproduced, so currently we can't say much from the test results. Srihari, do you still have the system around? Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Tejun, I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. Thanks, -Andrew On Jan 24, 2008 7:21 PM, Tejun Heo [EMAIL PROTECTED] wrote: Hello, Shane. Sorry about the delay. Got caught up in other stuff. Shane Huang wrote: Quoting Tejun: Uh-oh, wait a bit. Nope. Until we figure out what the something else is and positively verify 64bit DMA works fine, the quirk stays in. Our HW engineer has confirmed that our SB600 SATA controller indeed has some MSI issue, and we do not have any workaround. The workaround quirk_msi_intx_disable_bug to SB700 SATA controller can NOT work to SB600 SATA controller in my debug, while disablement to RS690 MSI in kernel source can fix it. Hmmm... Okay. Is the SB600 SATA controller culprit or the north bridge - RS690? If the former is the case, proper way to work around it is to add AHCI_HFLAG_NO_MSI for SB600 AHCI. As to the SB600 64 bit DMA capacity, do you have any methods to do further verification? I do NOT find any problem in my debug after I disabled RS690 MSI in kernel 2.6.24-rc7. The problem is that we didn't actually prove anything. In the tests you've done, pci=nomsi didn't fix the problem but disable_all_msi quirk did. pci=nomsi and disable_all_msi quirk are identical. Also, Srihari's problem was not reproduced, so currently we can't say much from the test results. Srihari, do you still have the system around? Thanks. -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About forcing 32bit DMA patch for AMD690G(SB600)
Andrew Paprocki wrote: I have an SB600/RS690 here with SATA drives connected. I haven't been following this thread, but I can help test something if it would help. We're trying to determine whether SB600 ahci controller can do 64bit DMA or not. Srihari's couldn't but Shane's test result tells a different story. Do you have memory mapped over 4G (if you have 4G some of them will be over 4G, you can know this by looking at the e820 map printed during boot)? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: About forcing 32bit DMA patch for AMD690G(SB600)
Hi Jeff: Do you have any suggestion on my plan to withdraw Tejun's forcing 32 bit DMA patch? As well as further validation to the 64 bit DMA capacity of SB600 SATA controller? Thanks Best Regards Shane -Original Message- From: Shane Huang Sent: Wednesday, January 23, 2008 3:44 PM To: [EMAIL PROTECTED]; 'Tejun Heo' Cc: 'linux-ide@vger.kernel.org'; Shane Huang Subject: About forcing 32bit DMA patch for AMD690G(SB600) Importance: High Resending this mail and adding linux-ide mail list... Quoting Tejun: Uh-oh, wait a bit. Nope. Until we figure out what the something else is and positively verify 64bit DMA works fine, the quirk stays in. Our HW engineer has confirmed that our SB600 SATA controller indeed has some MSI issue, and we do not have any workaround. The workaround quirk_msi_intx_disable_bug to SB700 SATA controller can NOT work to SB600 SATA controller in my debug, while disablement to RS690 MSI in kernel source can fix it. As to the SB600 64 bit DMA capacity, do you have any methods to do further verification? I do NOT find any problem in my debug after I disabled RS690 MSI in kernel 2.6.24-rc7. Thanks Best Regards Shane -Original Message- From: Shane Huang Sent: Wednesday, January 23, 2008 2:56 PM To: [EMAIL PROTECTED] Cc: 'Tejun Heo'; Shane Huang Subject: About forcing 32bit DMA patch for AMD690G(SB600) Importance: High Hi Srihari: This Shane @ AMD. I'm sorry to disturb you. I find that there is one patch which forces SB600 use 32bit DMA: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi t;h=c7a42156d99bcea7f8173ba7a6034bbaa2ecb77c This patch was submitted by Tejun to fix one issue on your platform: http://marc.info/?l=linux-idem=117810966106759w=2 But after a discussion with our hardware engineers, Tejun(the patch author), and some debugging, we believe that that SB600 can support 64 bit DMA, the root cause should be something else, while disablement to RS690 MSI in kernel source can be the workaround. So, we are going withdraw Tejun's patch ASAP. I wonder whether you still have that AMD690G platform or not? Are you able to help to do further confirmation before we withdraw it? You can just download kernel 2.6.21.1(which was used when you reported the bug), apply the attached disable_RS690_MSI.patch, and build the kernel. Please tell me if that patch can fix your issue without Tejun's patch. This patch has been proved to work on my RS690+SB600 under Fedora7 x86_64. You can also try my another disable_MSI_and_withdraw_32bit.patch under linux kernel 2.6.24-rc7, to see whether this patch can fix your issue too. This method also can work on my RS690+SB600 platform. Thanks waiting for your test result~~~ :-) Best Regards Shane - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
