Re: disabling sata_nv ADMA for 2.6.24

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Tejun Heo wrote:
Tejun Heo wrote:
Robert Hancock wrote:
This has only been reported on one person's MSI board. Apparently
another revision of the same board is reported to work, and I can't
duplicate the problem on my Asus board, so it could just be some
hardware problem on that motherboard.
IIRC, I have two from suse bug reports and both resolved with adma=0.
I'm not too sure whether post 2.6.23-rcX changes would have fixed those
problems tho.  FWIW, I've disabled ADMA mode on all suse products.
A hotplug-related problem? Have a link to the reports?
Hmmm... I mis-remembered.  The reporter said it was okay in SL102
(2.6.18, no ADMA) but SL103 (2.6.22, ADMA is on) fell apart.  I asked
for retest w/ adma=0 but no response yet.

  https://bugzilla.novell.com/show_bug.cgi?id=347184

I tried to reproduce the problem on my a8n-e but couldn't.

Okay, just succeeded on the current #upstream-fixes, attaching the log.
 The machine is a brick after the crash.

I assume the cable got reconnected at 325 seconds? It looks like that was during error handling for the previous unplug?

[  314.987885] ata3: timeout waiting for ADMA IDLE, stat=0x400
[  314.993556] ata3: timeout waiting for ADMA LEGACY, stat=0x400
[ 315.009915] ata3.00: exception Emask 0x10 SAct 0x1 SErr 0x1910000 action 0xa frozen
[  315.017708] ata3.00: ADMA status 0x00000402: , hot unplug
[  315.017714] ata3: SError: { PHYRdyChg Dispar LinkSeq TrStaTrns }
[ 315.029239] ata3.00: cmd 60/01:00:92:d7:12/00:00:05:00:00/40 tag 0 ncq 512 in [ 315.029240] res 40/00:04:92:d7:12/00:04:92:d7:12/40 Emask 0x10 (ATA bus error)
[  315.029243] ata3.00: status: { DRDY }
[  315.048236] ata3: hard resetting link
[  315.774982] ata3: SATA link down (SStatus 0 SControl 300)
[  315.780498] ata3: failed to recover some devices, retrying in 5 secs
[  320.788427] ata3: hard resetting link
[  325.242220] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

Not sure if the port would be frozen at this point or not?

It would be useful to add some printks to narrow down at what point the lockup happens. If it's a loop, interrupt storm or something then we can likely fix it, but if the controller's just locking up then we may be out of luck..
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux