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)
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)
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: > 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)
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)
Good news! (so far)
I've got a M2A-VM HDMI with 4 Gigs, some of that is mapped over the 4G
barrier. I patched the 2.6.24 kernel to allow the SB600 to do 64-bit
DMA. Then I ran a torture test overnight, copying the /usr tree 30
times while at the same time looping through a kernel compile 30 times.
No abnormal messages at all. Dmesg is clean, syslog is clean.
On another note I think Asus, or more accurately their BIOS vendor, has
improved the M2A-VM BIOS quite a bit lately. I'm using
version 1603. FlashRom from coreboot.org will successfully flash the
BIOS on the M2A-VM's! No more DOS/Windows required for BIOS updates on
this board.
--- ./drivers/ata/ahci.c.orig 2008-01-24 15:58:37.0 -0700
+++ ./drivers/ata/ahci.c2008-01-29 01:30:25.567532947 -0700
@@ -423,8 +423,11 @@ static const struct ata_port_info ahci_p
},
/* board_ahci_sb600 */
{
+/*
AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL |
AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_PMP),
+*/
+ AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL |
AHCI_HFLAG_NO_PMP),
.flags = AHCI_FLAG_COMMON,
.link_flags = AHCI_LFLAG_COMMON,
.pio_mask = 0x1f, /* pio0-4 */
Linux version 2.6.24-myKsmp ([EMAIL PROTECTED]) (gcc version 4.1.2) #1 SMP Tue
Jan 29 01:41:13 MST 2008
Command line: BOOT_IMAGE=myK-2.6.24 ro root=803
BIOS-provided physical RAM map:
BIOS-e820: - 0009f000 (usable)
BIOS-e820: 0009f000 - 000a (reserved)
BIOS-e820: 000f - 0010 (reserved)
BIOS-e820: 0010 - d7ee (usable)
BIOS-e820: d7ee - d7ee3000 (ACPI NVS)
BIOS-e820: d7ee3000 - d7ef (ACPI data)
BIOS-e820: d7ef - d7f0 (reserved)
BIOS-e820: e000 - f000 (reserved)
BIOS-e820: fec0 - 0001 (reserved)
BIOS-e820: 0001 - 00012000 (usable)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 884448) 1 entries of 256 used
Entering add_active_range(0, 1048576, 1179648) 2 entries of 256 used
end_pfn_map = 1179648
DMI 2.4 present.
ACPI: RSDP 000F82B0, 0024 (r2 ATI )
ACPI: XSDT D7EE3100, 004C (r1 ATIASUSACPI 42302E31 AWRD0)
ACPI: FACP D7EE8500, 00F4 (r3 ATIASUSACPI 42302E31 AWRD0)
ACPI: DSDT D7EE3280, 5213 (r1 ATIASUSACPI 1000 MSFT 300)
ACPI: FACS D7EE, 0040
ACPI: SSDT D7EE8740, 0248 (r1 PTLTD POWERNOW1 LTP1)
ACPI: HPET D7EE8A00, 0038 (r1 ATIASUSACPI 42302E31 AWRD 98)
ACPI: MCFG D7EE8A80, 003C (r1 ATIASUSACPI 42302E31 AWRD0)
ACPI: APIC D7EE8640, 0084 (r1 ATIASUSACPI 42302E31 AWRD0)
Entering add_active_range(0, 0, 159) 0 entries of 256 used
Entering add_active_range(0, 256, 884448) 1 entries of 256 used
Entering add_active_range(0, 1048576, 1179648) 2 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
DMA324096 -> 1048576
Normal1048576 -> 1179648
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
0:0 -> 159
0: 256 -> 884448
0: 1048576 -> 1179648
On node 0 totalpages: 1015423
DMA zone: 56 pages used for memmap
DMA zone: 1274 pages reserved
DMA zone: 2669 pages, LIFO batch:0
DMA32 zone: 14280 pages used for memmap
DMA32 zone: 866072 pages, LIFO batch:31
Normal zone: 1792 pages used for memmap
Normal zone: 129280 pages, LIFO batch:31
Movable zone: 0 pages used for memmap
ATI board detected. Disabling timer routing over 8254.
ACPI: PM-Timer IO Port: 0x4008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 4, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x8200 base: 0xfed0
Using ACPI (MADT) for SMP configuration information
swsusp: Registered nosave memory region: 0009f000 - 000a
swsusp: Registered nosave memory region: 000a - 000f
swsusp: Registered nosave memory region: 000f - 0010
swsusp: Registered nosave memory region: d7ee - d7ee3000
swsusp: Registered n
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- SERR- http://vger.kernel.org/majordomo-info.html
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)
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)
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)
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)
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)
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)
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-ide&m=117810966106759&w=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
