Bug 14275
| Summary: | kernel>=2.6.31: ahci.c: do not force unconditionally sb600 to 32bit dma any more? | ||
|---|---|---|---|
| Product: | IO/Storage | Reporter: | gabriele balducci (balducci) |
| Component: | Serial ATA | Assignee: | Tejun Heo (tj) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | rjw, shane.huang |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | >=2.6.31 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 13615 | ||
| Attachments: | sb600-32bit-only-by-default.patch | ||
bug#14311 is probably the same problem and you're right. Enabling 64bit DMA on sb600 just doesn't seem to worth all these regressions. All these machines have iommu anyway. Shane, I'm disabling 64bit dma for all sb600's. Thanks. Created attachment 23246 [details]
sb600-32bit-only-by-default.patch
Can you please verify this patch?
(In reply to comment #3) > Created an attachment (id=23246) [details] > sb600-32bit-only-by-default.patch > > Can you please verify this patch? sorry for the delay: I was out for the weekend Patched 2.6.32rc1 and all works fine (I mean: the system boots without problems and sb600 is forced to 32bit dma). thanks and ciao gabriele Patch included upstream. Resolving as FIXED. Oooh, already marked as FIXED. Anyways, thanks. On Monday 12 October 2009, Chuck Ebbert wrote:
> On Mon, 12 Oct 2009 01:01:09 +0200 (CEST)
> "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
>
> >
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14275
> > Subject : kernel>=2.6.31: ahci.c: do not force unconditionally
> sb600 to 32bit dma any more?
> > Submitter : gabriele balducci <balducci@units.it>
> > Date : 2009-09-30 15:02 (12 days old)
> > Patch : http://bugzilla.kernel.org/show_bug.cgi?id=14275#c0
> >
>
> Already marked fixed in bugzilla.
>
> Fixed by commit 2fcad9d271
> ("ahci: disable 64bit DMA by default on SB600s")
>
> Not in 2.6.31-stable.
|
Hello, apologies if I am missing some blatant point. After upgrading from 2.6.30.5 to 2.6.31 one of my machines was not booting any more, complaining like this (sata disks): ata2.00: qc timeout (cmd 0xec) ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata1.00: qc timeout (cmd 0xec) ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4) ata3.00: qc timeout (cmd 0xa1) ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4) Same after installing 2.6.31.1. It turned out that the problem is the sb600 SATA controller lying about its 64bit dma capability. As far as I seem to understand from ahci.c perusal, in >=2.6.31 the sb600 is forced to 32bit dma *ONLY* on ASUS M2A-VM mother board, while it was unconditionally (?) reset to 32bit dma before 2.6.31. I am running on an ASROCK AliveXFire-eSATA2 mother board and experience the fake 64bit dma advertising of the sb600 controller. I know 0 (zero) about kernel and/or ATA coding; I can only say that the following patch: *** drivers/ata/ahci.c.ORIG Wed Sep 30 15:37:54 2009 --- drivers/ata/ahci.c Wed Sep 30 15:37:54 2009 *************** *** 433,438 **** --- 433,439 ---- [board_ahci_sb600] = { AHCI_HFLAGS (AHCI_HFLAG_IGN_SERR_INTERNAL | + AHCI_HFLAG_32BIT_ONLY | AHCI_HFLAG_NO_MSI | AHCI_HFLAG_SECT255), .flags = AHCI_FLAG_COMMON, .pio_mask = ATA_PIO4, fixes everything for me. My impression is that the sb600 forcing should be done in more cases than the single ASUS M2A-VM, or even unconditionally like it used to be before 2.6.31 (but, as I said above, my understanding is poor and I might be totally wrong). I will be glad to send any other detail (dmesg, lspci, mobo specs, ...) if needed. Hope that libata people will fix this problem easily. thanks for all your work ciao gabriele