date:20070525

Henry Su wrote:
  Hi Jeff,
 Thanks for your kindly help, I will fix the email next time.
 Do you mean all the device IDs for ATI SB700 are added to the corresponding 
 files?
 because I split this patch and resent four patches according to your last 
 suggestion,
 if this patch is applied, another patches are  not necessary now.

Splitting up the patches helped us all.  The AHCI, drivers/ide, and now
pata_atiixp patches were applied by the respective maintainers.  Let me
know if you need a quick introduction to git, which is the main tool to
watch the latest Linux kernel source code (it's like CVS, but better :))

I don't know about the SMBus patch, though.  That may or may not have
been applied.

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

VIA VT6420: SATA disconnects

2007-05-25 Thread Vasily Averin

Jeff, Tejun,

Our RHEL5-based OpenVZ linux kernel reports about SATA-related issues:
VIA VT6420 SATA RAID Controller on MSI motherboard, x86_64 kernel based on 
latest RHEL5 kernel,
On booting hardware initialized properly and all works fine some time, but then 
it detects timeout and disables devices. We have replaced SATA cables, but 
issue didn't go away and still present.

I've googled and found similair bugreport in linux-ide@
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06011.html

Are you know something about this issue? I've seen that you have fixed SATA 
reset procedure recently, probably this issue was fixed already?

thank you,
Vasily Averin

OpenVZ/Virtuozzo Linux kernel Team

May 24 09:39:39 ts28 SCSI subsystem initialized
May 24 09:39:39 ts28 libata version 2.00 loaded.
May 24 09:39:39 ts28 sata_via :00:0f.0: version 2.0
May 24 09:39:39 ts28 ACPI: PCI Interrupt :00:0f.0[B] - Link [ALKA] - GSI 
20 (level, low) - IRQ 169
May 24 09:39:39 ts28 sata_via :00:0f.0: routed to hard irq line 11
May 24 09:39:39 ts28 ata1: SATA max UDMA/133 cmd 0xC000 ctl 0xC402 bmdma 0xD000 
irq 169
May 24 09:39:39 ts28 ata2: SATA max UDMA/133 cmd 0xC800 ctl 0xCC02 bmdma 0xD008 
irq 169
May 24 09:39:39 ts28 scsi0 : sata_via
May 24 09:39:39 ts28 ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
May 24 09:39:40 ts28 ata1.00: ATA-7, max UDMA/133, 156301488 sectors: LBA48 NCQ 
(depth 0/32)
May 24 09:39:40 ts28
May 24 09:39:40 ts28 ata1.00: ata1: dev 0 multi count 16
May 24 09:39:40 ts28 ata1.00: configured for UDMA/133
May 24 09:39:40 ts28 scsi1 : sata_via
May 24 09:39:40 ts28 ata2: SATA link down 1.5 Gbps (SStatus 0 SControl 300)
May 24 09:39:40 ts28 ATA: abnormal status 0x7F on port 0xC807
May 24 09:39:40 ts28   Vendor: ATA   Model: ST380811ASRev: 3.AA
May 24 09:39:40 ts28   Type:   Direct-Access  ANSI SCSI 
revision: 05
May 24 09:39:40 ts28 SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
May 24 09:39:40 ts28 sda: Write Protect is off
May 24 09:39:40 ts28 sda: Mode Sense: 00 3a 00 00
May 24 09:39:40 ts28 SCSI device sda: drive cache: write back
May 24 09:39:40 ts28 SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
May 24 09:39:40 ts28 sda: Write Protect is off
May 24 09:39:40 ts28 sda: Mode Sense: 00 3a 00 00
May 24 09:39:40 ts28
May 24 09:39:40 ts28 SCSI device sda: drive cache: write back
May 24 09:39:40 ts28  sda: sda1 sda2 sda3 sda4  sda5 
May 24 09:39:40 ts28 sd 0:0:0:0: Attached scsi disk sda
May 24 09:39:43 ts28 kjournald starting.  Commit interval 5 seconds
May 24 09:39:43 ts28 EXT3-fs: mounted filesystem with ordered data mode.
May 24 09:53:15 ts28 ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 
frozen
May 24 09:53:15 ts28 ata1.00: (BMDMA stat 0x4)
May 24 09:53:15 ts28 ata1.00: tag 0 cmd 0xca Emask 0x4 stat 0x40 err 0x0 
(timeout)
May 24 09:53:46 ts28 ata1.00: qc timeout (cmd 0xec)
May 24 09:53:46 ts28 ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
May 24 09:53:46 ts28 ata1.00: revalidation failed (errno=-5)
May 24 09:53:46 ts28 ata1: failed to recover some devices, retrying in 5 secs
May 24 09:54:23 ts28 ata1.00: qc timeout (cmd 0xec)
May 24 09:54:23 ts28 ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
May 24 09:54:23 ts28 ata1.00: revalidation failed (errno=-5)
May 24 09:54:23 ts28 ata1: failed to recover some devices, retrying in 5 secs
May 24 09:54:59 ts28 ata1.00: qc timeout (cmd 0xec)
May 24 09:54:59 ts28 ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
May 24 09:54:59 ts28 ata1.00: revalidation failed (errno=-5)
May 24 09:54:59 ts28 ata1.00: disabled


Linux ts28 2.6.18-028stab031.1 #1 SMP Fri Apr 27 18:39:46 MSD 2007 x86_64 
x86_64 x86_64 GNU/Linux

00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID 
Controller (rev 80)
Subsystem: Micro-Star International Co., Ltd. Unknown device 1300
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 32
Interrupt: pin B routed to IRQ 169
Region 0: I/O ports at c000 [size=8]
Region 1: I/O ports at c400 [size=4]
Region 2: I/O ports at c800 [size=8]
Region 3: I/O ports at cc00 [size=4]
Region 4: I/O ports at d000 [size=16]
Region 5: I/O ports at d400 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 06 11 49 31 07 00 90 02 80 00 04 01 00 20 80 00
10: 01 c0 00 00 01 c4 00 00 01 c8 00 00 01 cc 00 00
20: 01 d0 00 00 01 d4 00 00 00 00 00 00 62 14 00 13
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0b 02 00 00
40: 33 03 f1 44 06 af 00 00 10 82 65 03 00 00 00 00
50: 00 00 00 00 00 00 04 04 00 10 10 00 05 00 20 00
60: 01 00 00 00 00 00 00 00 00 00 00

Re: VIA VT6420: SATA disconnects


Vasily Averin wrote:

Jeff, Tejun,

Our RHEL5-based OpenVZ linux kernel reports about SATA-related issues:
VIA VT6420 SATA RAID Controller on MSI motherboard, x86_64 kernel based on 
latest RHEL5 kernel,
On booting hardware initialized properly and all works fine some time, but then 
it detects timeout and disables devices. We have replaced SATA cables, but 
issue didn't go away and still present.

I've googled and found similair bugreport in linux-ide@
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06011.html

Are you know something about this issue? I've seen that you have fixed SATA 
reset procedure recently, probably this issue was fixed already?


RHEL5 SATA is unfortunately way out of date :(  The next RHEL5 update 
should include a boatload of fixes.


Try running the latest upstream kernel (2.6.21.3 or 2.6.22-rc2-git7), 
and see if the problem is reproducible.


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: [PATCH 2.6.22-rc2] libata: sata_sis fixes


Uwe Koziolek wrote:

--- a/drivers/ata/sata_sis.c2007-05-22 11:05:38.0 +0200
+++ b/drivers/ata/sata_sis.c2007-05-23 00:24:28.0 +0200
@@ -255,7 +255,7 @@
 {
static int printed_version;
struct ata_port_info pi = sis_port_info;
-   const struct ata_port_info *ppi[] = { pi, NULL };
+   const struct ata_port_info *ppi[] = { pi, pi };
struct ata_host *host;
u32 genctl, val;
u8 pmr;


applied this part



--- a/drivers/ata/pata_sis.c2007-05-22 11:05:38.0 +0200
+++ b/drivers/ata/pata_sis.c2007-05-25 07:50:50.0 +0200
@@ -146,7 +146,8 @@
 
 	struct pci_dev *pdev = to_pci_dev(ap-host-dev);
 
-	if (!pci_test_config_bits(pdev, sis_enable_bits[ap-port_no]))

+   if ((pdev-device != 0x0180)  (pdev-device != 0x0181) 
+   !pci_test_config_bits(pdev, sis_enable_bits[ap-port_no]))
return -ENOENT;
 
 	return ata_std_prereset(ap, deadline);


I think you misunderstood what Alan and I were saying.

If you remove the enable-bits check, then logically, all the function 
does is call ata_std_prereset.  Thus, your error handler only needs to 
the standard function for 0x180 and 0x181, ata_std_prereset() rather 
than sis_pre_reset().


Further, once your ata_bmdma_drive_eh() has been reduced entirely to 
calling standard functions, you need not use sis_error_handler() at all, 
because _that_ has been reduced to ata_bmdma_error_handler().


As a result, the following line

.error_handler  = ata_bmdma_error_handler,

is functionally equivalent to your patch, but without custom code to 
produce that effect.


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: [patch 03/11] Optional LED trigger for libata

2007-05-25 Thread Tony Vroon

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jeff Garzik wrote:
 [EMAIL PROTECTED] wrote:
 From: Tony Vroon [EMAIL PROTECTED]

 This adds an optional wrapper around ata_ac_issue_prot that triggers the
 LED layer.  This is used for the PMU LED on G5 towers (IDE trigger).  My
 test platform is a PowerMac 7,3 (Dual G5 2.0GHz, June 2004) with a K2
 (sata_svw) controller.  Now respun as a single patch, and the function
 name
 shortened as requested.

 Signed-off-by: Tony Vroon [EMAIL PROTECTED]
 Acked-by: Tejun Heo [EMAIL PROTECTED]
 Cc: Jeff Garzik [EMAIL PROTECTED]
 Signed-off-by: Andrew Morton [EMAIL PROTECTED]
 ---

  drivers/ata/libata-core.c |   21 +
  drivers/ata/sata_svw.c|2 +-
  include/linux/libata.h|1 +
  3 files changed, 23 insertions(+), 1 deletion(-)
 
 
 After sitting on this for a time, I still cannot summon any interest in
 taking this patch.  It slows down the hot path for pretty lights.

Jeff,

Would a conditional on ADB_PMU_LED_IDE (instead of the more generic
LEDS_TRIGGER_IDE_DISK) alleviate your concerns? This can only be enabled
on PPC platforms and would make sure that the hot path is not polluted
anywhere else.

Regards,
Tony V.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGVp/yp5vW4rUFj5oRCOlXAJwMpRiboqDnMcFdHxX7BU+Y1S1SxACePgeP
q4yyJJzNBeJeF1YakPXrIOo=
=ehsX
-END PGP SIGNATURE-
-
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: JMicron JMB363 issue fixed / ICH8 RAID volume trace

Andrew Paprocki wrote:
 Tejun, fdisk -l output is attached
 
 Basically, in the ICH8 BIOS:
 /dev/sda + sdb = 2 500GB drives in RAID1 configuration
 /dev/sdc + sdd + sde + sdf = 4 320GB drives in RAID5 configuration
 
 /dev/sdg is a 320GB boot drive connected to the JMB363 chipset
 
 Is there some kind of problem when probing these partitions because
 they are fake software RAID through the ICH8? The messages only spew
 at boot time.

OIC, you need to use dm-raid to use those fake RAIDs properly.  If you
don't intend to access the RAIDs, you don't need to care.

-- 
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: VIA VT6420: SATA disconnects

2007-05-25 Thread Vasily Averin

Jeff Garzik wrote:
 RHEL5 SATA is unfortunately way out of date :(  The next RHEL5 update 
 should include a boatload of fixes.

Is SATA update included into RHEL5 testkernels? And do you probably know if 
they are accessible somewhere (like in http://people.redhat.com/~jbaron/rhel4/ 
for RHEL4 testkernels)?

thank you,
Vasily Averin
-
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: [PATCH] libata: always use polling SETXFER


Tejun Heo wrote:

Several people have reported LITE-ON LTR-48246S detection failed
because SETXFER fails.  It seems the device raises IRQ too early after
SETXFER.  This is controller independent.  The same problem has been
reported for different controllers.

So, now we have pata_via where the controller raises IRQ before it's
ready after SETXFER and a device which does similar thing.  This patch
makes libata always execute SETXFER via polling.  As this only happens
during EH, performance impact is nil.  Setting ATA_TFLAG_POLLING is
also moved from issue hot path to ata_dev_set_xfermode() - the only
place where SETXFER can be issued.

Jeff Garzik suggests that, in the long term, it might be better to
modify libata HSM implementation such that we're more tolerant of
erratic ATAPI IRQ behavior - e.g. default to IRQ but falling back to
polling if the device doesn't seem ready at the point of interrupt.
Such change might be necessary to support ancient/weird ATAPI devices.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]


Since I wrote them up in IRC, I might as well post them here and get it 
archived:


We need to figure out a better polling solution.

For SAS and advanced SATA, polling really has no meaning at all, when 
you consider what polling IDENTIFY DEVICE and polling SET FEATURES are 
trying to solve.  To the advanced hardware, it's all a bunch of packets. 
 An event that appears late to the eyes of the PATA world is now 
presented as changing data fields in the packet stream.


We are going to have to deal with the HSM issue underlying the need to 
do SET FEATURES - XFER MODE polling, and ultimately IDENTIFY DEVICE 
polling too.


This is the main reason why I have resisted applying [PATCH] libata: 
always use polling SETXFER -- polling implies a model that does not 
exist on SAS/SATA and advanced SATA.  It's only luck that AHCI includes 
a real register to poll.


To illustrate:  Fixing this problem The Right Way(tm) will yield a 
result that would allow ahci.c to operate in an interrupt-driven mode, 
examining the contents of the FIS's returned. Polling status can already 
be replaced by examining the D2H and SDB FIS areas.


And by definition, on AHCI (and sata_sil24, IIRC) the status will not 
change unless a new FIS has arrived.


Polling is still fine on PCI IDE-like controllers (older ones), but 
advanced controllers require us to coalesce the polling bandaid into a 
test for a sequence of events.


We cannot escape the hard part.  :)

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: [patch] Add the device IDs for AMD/ATI SB700

Henry Su wrote:
I check the latest kernel source code with git, and find out that the SMBus patch has not been applied yet,

Correct. When you don't see a patch in the upstream git tree
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
then the next step is consult the MAINTAINERS file, and determine to
whom you should send a follow-up patch, or simply contact about the
status of a patch you just sent. In this case, SMBus is in drivers/i2c
sub-directory, which leads us to find in MAINTAINERS,

I2C SUBSYSTEM
P: Jean Delvare
M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
T: quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
S: Maintained

That tells us the maintainer of the subsystem, and also (T:) an
external reference (a tree) to where the maintainer posts accepted
patches, prior to sending them upstream.

So for SMBus, you should make sure your SMBus changes appear in Jean
Delvare's quilt tree. If they do not, create a new patch and send it to
Jean and CC [EMAIL PROTECTED] and [EMAIL PROTECTED]

and the patch for IDE has not been applied completely.one more device id
should be added to pata_atiixp.c,
l list the patch as following, or you can fetch it from the attached file, could you please apply this for me?

Actually it has been applied -- the part that I maintain (drivers/ata/*)
is currently stored in a secondary tree, as described above. Your patch
has been stored on the 'upstream' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git

Currently, the upstream Linux kernel is only accepting bug fixes. I
merge ATA bug fixes (and sometimes simple PCI ID additions) into
libata-dev.git#upstream-fixes during this phase of development. These
changes are sent upstream in 24-48 hours, to ensure that they will be
included in the next release (kernel 2.6.22).

All other ATA changes are merged into libata-dev.git#upstream. When
Linus releases kernel 2.6.22, the merge window opens, allowing
non-bug-fix changes to be submitted upstream. When the merge window
opens, I submit everything in libata-dev.git#upstream to Linus and
Andrew Morton for inclusion in the official upstream kernel tree.

That is our development process in a nutshell.

The kernel development process is conducted entirely via email, so you
see why it is so important to learn how to email patches in the proper
format.

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: [PATCH] libata: Add MMIO support to pata_sil680

2007-05-25 Thread Mark Lord


Benjamin Herrenschmidt wrote:

On Thu, 2007-05-24 at 16:56 -0400, Mark Lord wrote:

Benjamin Herrenschmidt wrote:

The only thing that I'm wondering about a bit is that ata_pause so far
uses read of altstatus which _is_ a taskfile register. It's my
understanding that we should avoid doing so in that case.

Technically, altstatus is in the control block rather than the command block,
so it doesn't really always behave the same as the regular taskfile regs.


So would altstatus be good enough to flush SRST toggles as well or do
you expect problems ?


Dunno, really.  If one didn't have a known better idea, then it's worth trying.
-
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: [PATCH] libata: always use polling SETXFER

Jeff Garzik wrote:
 Tejun Heo wrote:
 So, I don't think the problem exists for SATA in the first place.  At
 least there hasn't been any report of it and doing SETXFER by polling
 can handle all the existing cases.  We can and probably should deal with
 such SATA devices when and if they come up.  How are we gonna verify the
 controller doesn't crap itself and ahci TF register monitoring HSM can
 work around the weirdo when we don't have any such device?  Even if we
 determine that we need to do HSM over intelligent SATA controller now, I
 think we still need to push polling SETXFER first to take care of the
 existing cases.
 
 Doing SETXFER by polling only handles the cases where the driver
 actually honors ATA_TFLAG_POLLING, which is /not/ always the case.
 
 If the new policy ensures that it continues to be OK to /not/ honor
 ATA_TFLAG_POLLING -- thus limiting SETXFER polling assumptions to older
 hardware -- that's fine, and it merely needs to be documented.

Basically this flag applies to drivers which is SFF compliant, at least
at TF interface level.  There also are other flags/callbacks which only
apply to SFF or BMDMA.  It would be nice to separate them out in the
long term and yeah it needs documentation.

 But let us not make the assumption that this bandaid fixes all cases,
 because the bandaid is not applied in all cases.

It covers all the known cases but I agree that SFF specific things
certainly need documentation.

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: [PATCH] libata: always use polling SETXFER

Hello, Jeff.

Jeff Garzik wrote:
 Since I wrote them up in IRC, I might as well post them here and get it
 archived:

Just about to reply on IRC.  :-)

 We need to figure out a better polling solution.
 
 For SAS and advanced SATA, polling really has no meaning at all, when
 you consider what polling IDENTIFY DEVICE and polling SET FEATURES are
 trying to solve.  To the advanced hardware, it's all a bunch of packets.
  An event that appears late to the eyes of the PATA world is now
 presented as changing data fields in the packet stream.
 
 We are going to have to deal with the HSM issue underlying the need to
 do SET FEATURES - XFER MODE polling, and ultimately IDENTIFY DEVICE
 polling too.
 
 This is the main reason why I have resisted applying [PATCH] libata:
 always use polling SETXFER -- polling implies a model that does not
 exist on SAS/SATA and advanced SATA.  It's only luck that AHCI includes
 a real register to poll.
 
 To illustrate:  Fixing this problem The Right Way(tm) will yield a
 result that would allow ahci.c to operate in an interrupt-driven mode,
 examining the contents of the FIS's returned. Polling status can already
 be replaced by examining the D2H and SDB FIS areas.
 
 And by definition, on AHCI (and sata_sil24, IIRC) the status will not
 change unless a new FIS has arrived.
 
 Polling is still fine on PCI IDE-like controllers (older ones), but
 advanced controllers require us to coalesce the polling bandaid into a
 test for a sequence of events.
 
 We cannot escape the hard part.  :)

I don't think the hard part exists at all.

1. There are only a handful of PATA devices which raise IRQ too early.
For native SATA devices, it's much more difficult to get it wrong if you
consider the SATA non-data and PIO transport protocol.  For PATA devices
bridged to SATA, again, there's nothing much we can do.  The bridge
implements HSM and would send D2H Reg FIS on command completion IRQ.  If
the PATA shows incorrect register values at that stage, well, that's it.

3. Intelligent controllers such as AHCI and sil24 implement some part of
HSM in the silicon.  sil24 implements most of it, ahci a bit less, but,
even for ahci, the too early interrupt can trigger internal HSM failure.
 I don't think we can do much in such cases.  sil24 doesn't even update
the TF area if command is not in progress.  In the intelligent
controllers, the problem polling SETXFER tries to solve is in lower
layer than OS driver.

So, I don't think the problem exists for SATA in the first place.  At
least there hasn't been any report of it and doing SETXFER by polling
can handle all the existing cases.  We can and probably should deal with
such SATA devices when and if they come up.  How are we gonna verify the
controller doesn't crap itself and ahci TF register monitoring HSM can
work around the weirdo when we don't have any such device?  Even if we
determine that we need to do HSM over intelligent SATA controller now, I
think we still need to push polling SETXFER first to take care of the
existing cases.

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: [PATCH] libata: always use polling SETXFER


Tejun Heo wrote:

So, I don't think the problem exists for SATA in the first place.  At
least there hasn't been any report of it and doing SETXFER by polling
can handle all the existing cases.  We can and probably should deal with
such SATA devices when and if they come up.  How are we gonna verify the
controller doesn't crap itself and ahci TF register monitoring HSM can
work around the weirdo when we don't have any such device?  Even if we
determine that we need to do HSM over intelligent SATA controller now, I
think we still need to push polling SETXFER first to take care of the
existing cases.


Doing SETXFER by polling only handles the cases where the driver 
actually honors ATA_TFLAG_POLLING, which is /not/ always the case.


If the new policy ensures that it continues to be OK to /not/ honor 
ATA_TFLAG_POLLING -- thus limiting SETXFER polling assumptions to older 
hardware -- that's fine, and it merely needs to be documented.


But let us not make the assumption that this bandaid fixes all cases, 
because the bandaid is not applied in all cases.


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: [PATCH] libata: Add MMIO support to pata_sil680

On Thu, 24 May 2007 20:51:26 -0400
Jeff Garzik [EMAIL PROTECTED] wrote:

 Alan Cox wrote:
  #define DELAY400NS  { pio_inbyte( CB_ASTAT ); pio_inbyte( CB_ASTAT );  \
 pio_inbyte( CB_ASTAT ); pio_inbyte( CB_ASTAT ); }
 
 
  
  Totally unrelated. Hal is using the cycle time of the four I/O reads to
  do the 400nS delay. Its a neat way to do the delay on boxes without
  modern CPUs and nice timing features and perhaps one we should use on
  those boxes but its not relevant to the question of how you post an MMIO
  command write.
 
 It illustrates (as well as our experience to date) that AltStatus use 
 for the delay is just fine.

Correct, but it is also extremely slow. No point discussing fast paths
for odd if() tests through the code when you burn 100nS unneccessarily
every time you issue a command via PIO is there.

Alan
-
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: 2.6.22-rc1-mm1: IDE compile error

  To set it up the user will have to know the parameters and have typed
  them into the BIOS (if it even has an option for it). I see no problem
 
 Sorry, see no problem which way?  

Forcing the user to provide the geometry. Historically that driver dealt
with the main disks the user had. Today its only use is specialist
recovery work. Anyone recovering a disk has to get the geometry data into
the BIOS (if the BIOS even allows it - many now don't) and will therefore
know it for hd= arguments as well

Alan
-
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

[PATCH, RFT, v3] sata_mv: convert to new EH


Hi, linux-ide (and Dave and dean).

I'm looking for some sata_mv testing feedback.  Version 2 of this patch 
was reported to be triggering BUG_ON/WARN_ON messages in mv_qc_issue() 
and mv_get_crpb_status().


I'm looking for someone to be willing to give three sata_mv cases a 
quick test:

vanilla 2.6.21.X(latest 2.6.21)
vanilla 2.6.22-rc2-gitX (latest release candidate)
2.6.22-rc2-gitX + attachment(sata_mv new-EH test patch)

sata_mv saw several changes go into 2.6.22-rc, and I want to make sure 
the BUG_ON/WARN_ON messages do not trigger in the current -rc.  This 
will help me narrow down the source of the dmesg spam.


To answer one of dean's questions about NCQ, check out 
http://linux-ata.org/faq.html#ncq


Thanks,

Jeff



Jeff Garzik (9):
  [libata] sata_mv: first cut at new EH
  [libata] sata_mv: move PCI error handling into separate function
  [libata] sata_mv: handle PCI error properly, within new EH
  [libata] sata_mv: convert IRQ handler over to new EH
  [libata] sata_mv: clean up vestiges of old EH
  [libata] sata_mv EH: 50xx fixes, fold non-EDMA EH into EDMA EH path
  [libata] sata_mv: improve EH handling with additional hooks
  [libata] sata_mv: more EH fixes
  [libata mv-eh] sata_mv: build fix for cable detect

 drivers/ata/sata_mv.c |  457 ++
 1 file changed, 314 insertions(+), 143 deletions(-)

diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 705a020..57f2345 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -192,8 +192,10 @@ enum {
EDMA_ERR_DEV_DCON   = (1  3),
EDMA_ERR_DEV_CON= (1  4),
EDMA_ERR_SERR   = (1  5),
-   EDMA_ERR_SELF_DIS   = (1  7),
+   EDMA_ERR_SELF_DIS   = (1  7), /* Gen II/IIE self-disable */
+   EDMA_ERR_SELF_DIS_5 = (1  8), /* Gen I self-disable */
EDMA_ERR_BIST_ASYNC = (1  8),
+   EDMA_ERR_TRANS_IRQ_7= (1  8), /* Gen IIE transprt layer irq */
EDMA_ERR_CRBQ_PAR   = (1  9),
EDMA_ERR_CRPB_PAR   = (1  10),
EDMA_ERR_INTRL_PAR  = (1  11),
@@ -204,13 +206,33 @@ enum {
EDMA_ERR_LNK_CTRL_TX= (0x1f  21),
EDMA_ERR_LNK_DATA_TX= (0x1f  26),
EDMA_ERR_TRANS_PROTO= (1  31),
-   EDMA_ERR_FATAL  = (EDMA_ERR_D_PAR | EDMA_ERR_PRD_PAR |
-  EDMA_ERR_DEV_DCON | EDMA_ERR_CRBQ_PAR |
-  EDMA_ERR_CRPB_PAR | EDMA_ERR_INTRL_PAR |
-  EDMA_ERR_IORDY | EDMA_ERR_LNK_CTRL_RX_2 |
-  EDMA_ERR_LNK_DATA_RX |
-  EDMA_ERR_LNK_DATA_TX |
-  EDMA_ERR_TRANS_PROTO),
+   EDMA_ERR_OVERRUN_5  = (1  5),
+   EDMA_ERR_UNDERRUN_5 = (1  6),
+   EDMA_EH_FREEZE  = EDMA_ERR_D_PAR |
+ EDMA_ERR_PRD_PAR |
+ EDMA_ERR_DEV_DCON |
+ EDMA_ERR_DEV_CON |
+ EDMA_ERR_SERR |
+ EDMA_ERR_SELF_DIS |
+ EDMA_ERR_CRBQ_PAR |
+ EDMA_ERR_CRPB_PAR |
+ EDMA_ERR_INTRL_PAR |
+ EDMA_ERR_IORDY |
+ EDMA_ERR_LNK_CTRL_RX_2 |
+ EDMA_ERR_LNK_DATA_RX |
+ EDMA_ERR_LNK_DATA_TX |
+ EDMA_ERR_TRANS_PROTO,
+   EDMA_EH_FREEZE_5= EDMA_ERR_D_PAR |
+ EDMA_ERR_PRD_PAR |
+ EDMA_ERR_DEV_DCON |
+ EDMA_ERR_DEV_CON |
+ EDMA_ERR_OVERRUN_5 |
+ EDMA_ERR_UNDERRUN_5 |
+ EDMA_ERR_SELF_DIS_5 |
+ EDMA_ERR_CRBQ_PAR |
+ EDMA_ERR_CRPB_PAR |
+ EDMA_ERR_INTRL_PAR |
+ EDMA_ERR_IORDY,
 
EDMA_REQ_Q_BASE_HI_OFS  = 0x10,
EDMA_REQ_Q_IN_PTR_OFS   = 0x14, /* also contains BASE_LO */
@@ -244,6 +266,7 @@ enum {
/* Port private flags (pp_flags) */
MV_PP_FLAG_EDMA_EN  = (1  0),
MV_PP_FLAG_EDMA_DS_ACT  = (1  1),
+   MV_PP_FLAG_HAD_A_RESET  = (1  2),
 };
 
 #define IS_50XX(hpriv) ((hpriv)-hp_flags  MV_HP_50XX)
@@ -340,14 +363,14 @@ static u32 mv_scr_read(struct ata_port *ap, unsigned int 
sc_reg_in);
 static void mv_scr_write(struct ata_port *ap, unsigned int sc_reg_in, u32 val);
 static u32 mv5_scr_read(struct ata_port *ap, unsigned int sc_reg_in);
 static void mv5_scr_write(struct ata_port *ap, unsigned int sc_reg_in, u32 
val);
-static

Re: [PATCH 2.6.22-rc2] libata: sata_sis fixes

On Fri, 25 May 2007 09:48:52 +0200
Uwe Koziolek [EMAIL PROTECTED] wrote:

 The sata_sis driver supports SATA and PATA ports. The broken support
 of both types in one controller is fixed.
 
 the PATA-port of SiS180 controller does not support a drive present status
 in the pci configspace like the other SiS PATA controllers, check skipped.
 
 Signed-off-by: Uwe Koziolek [EMAIL PROTECTED]

Needs checking with SiS because they submitted code that uses those
enable bits and its been in drivers/ide for years with respect of the
MuTOL ATA133. No argument about the SATA one if you've checked the docs
and seen the bug.

 - if (!pci_test_config_bits(pdev, sis_enable_bits[ap-port_no]))
 + if ((pdev-device != 0x0180)  (pdev-device != 0x0181) 
 + !pci_test_config_bits(pdev, sis_enable_bits[ap-port_no]))
   return -ENOENT;

Might look a lot nicer with less brackets, or even better pull the device
check out into a new static function (gcc will inline it all nicely
anyway) so you can just say

if (sis_enables_supported(pdev)  !pci_test...

-
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: sil680 MMIO changes moved to branch

 Fine with me. I've been busy with other things and waiting for you and
 Alan to decide what should be done for the reset stuff anway :-)
 
 So Alan, do you think we should add something or do you think that just
 reading altstat like ata_pause does is good enough ?

Reading altstat is unneccessary for PIO so we do want to get these
changes in so we can sort out performance of command sending, pause and
anything else where it would help.

The PDC driver may well want to use altstatus reads for this but thats
driver specific.
-
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: VIA VT6420: SATA disconnects

2007-05-25 Thread Jan Evert van Grootheest


Jeff Garzik wrote:

Vasily Averin wrote:

Jeff, Tejun,

Our RHEL5-based OpenVZ linux kernel reports about SATA-related issues:
VIA VT6420 SATA RAID Controller on MSI motherboard, x86_64 kernel 
based on latest RHEL5 kernel,
On booting hardware initialized properly and all works fine some 
time, but then it detects timeout and disables devices. We have 
replaced SATA cables, but issue didn't go away and still present.


I've googled and found similair bugreport in linux-ide@
http://www.mail-archive.com/linux-ide@vger.kernel.org/msg06011.html

Are you know something about this issue? I've seen that you have 
fixed SATA reset procedure recently, probably this issue was fixed 
already?


RHEL5 SATA is unfortunately way out of date :(  The next RHEL5 update 
should include a boatload of fixes.


Try running the latest upstream kernel (2.6.21.3 or 2.6.22-rc2-git7), 
and see if the problem is reproducible.



Jeff,

In the meantime I've taken that disk out of use (although it is still in 
that same machine and connected). So I can easily run tests on it.
I'm not sure I want to build my own (somewhat recent) kernel, because 
that machine serves as our home server. It takes some engineering to 
find time where the family is gone and nobody needs it.
Also it uses xen and I don't know whether I can find the proper patches 
to get it to compile (I find it difficult in debian to find the patches 
that were used to produce a kernel). But if nobody uses it, I could do 
with a xen-less kernel. Hopefully bonnie or somesuch will make the 
problem appear.


Like Vasily I also had it connected to the VIA controller. But the 
problems also appeared when the disk was connected to the Promise 
controller on the same board. So I would, at first sight, not consider 
this a controller issue.


-- Jan Evert

-
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

[PATCH] ata_piix: fix pio/mwdma programming

Fix various bugs in pio/mwdma mode programming.

* Control bits in the timing register wasn't cleared properly while
  programming PIO mode.

* MWDMA mode programming cleared the wrong part of control bits.

* MWDMA mode programming cleared udma_mask even when the controller
  doesn't support UDMA.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Cc: Art Haas [EMAIL PROTECTED]
---
Patch is against libata-dev#upstream.  Thanks.

 drivers/ata/ata_piix.c |   23 +--
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 9c07b88..924e447 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -685,8 +685,14 @@ static void piix_set_piomode (struct ata
if (adev-class == ATA_DEV_ATA)
control |= 4;   /* PPE enable */
 
+   /* PIO configuration clears DTE unconditionally.  It will be
+* programmed in set_dmamode which is guaranteed to be called
+* after set_piomode if any DMA mode is available.
+*/
pci_read_config_word(dev, master_port, master_data);
if (is_slave) {
+   /* clear TIME1|IE1|PPE1|DTE1 */
+   master_data = 0xff0f;
/* Enable SITRE (seperate slave timing register) */
master_data |= 0x4000;
/* enable PPE1, IE1 and TIME1 as needed */
@@ -694,12 +700,14 @@ static void piix_set_piomode (struct ata
pci_read_config_byte(dev, slave_port, slave_data);
slave_data = (ap-port_no ? 0x0f : 0xf0);
/* Load the timing nibble for this slave */
-   slave_data |= ((timings[pio][0]  2) | timings[pio][1])  
(ap-port_no ? 4 : 0);
+   slave_data |= ((timings[pio][0]  2) | timings[pio][1])
+(ap-port_no ? 4 : 0);
} else {
-   /* Master keeps the bits in a different format */
-   master_data = 0xccf8;
+   /* clear ISP|RCT|TIME0|IE0|PPE0|DTE0 */
+   master_data = 0xccf0;
/* Enable PPE, IE and TIME as appropriate */
master_data |= control;
+   /* load ISP and RCT */
master_data |=
(timings[pio][0]  12) |
(timings[pio][1]  8);
@@ -816,7 +824,7 @@ static void do_pata_set_dmamode (struct
master_data = 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY 
*/
master_data |= control  4;
pci_read_config_byte(dev, 0x44, slave_data);
-   slave_data = (0x0F + 0xE1 * ap-port_no);
+   slave_data = (ap-port_no ? 0x0f : 0xf0);
/* Load the matching timing */
slave_data |= ((timings[pio][0]  2) | 
timings[pio][1])  (ap-port_no ? 4 : 0);
pci_write_config_byte(dev, 0x44, slave_data);
@@ -828,8 +836,11 @@ static void do_pata_set_dmamode (struct
(timings[pio][0]  12) |
(timings[pio][1]  8);
}
-   udma_enable = ~(1  devid);
-   pci_write_config_word(dev, master_port, master_data);
+
+   if (ap-udma_mask) {
+   udma_enable = ~(1  devid);
+   pci_write_config_word(dev, master_port, master_data);
+   }
}
/* Don't scribble on 0x48 if the controller does not support UDMA */
if (ap-udma_mask)
-
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: [PATCH pata-2.6 fix queue] hpt366: don't check enablebits for HPT36x

2007-05-25 Thread Linas Vepstas

On Fri, May 25, 2007 at 01:47:04AM +0400, Sergei Shtylyov wrote:
 Hello, I wrote:
 
   Linas, Andries, Michal, cound you try this instead:
 
 d-enablebits[0].mask = d-enablebits[0].val = 0x10;
 
It probably won't work the way it should anyway -- the secondary 
 channel (and controller in this case) uses another bit in this register 
 and the controllers get registered with IDE core in pair.

Setting d-enablebits[0].mask = d-enablebits[0].val = 0x10; makes
my system bootable, and so this works well enough for me.  Without this
patch, mainline 2.6.21.1 is broken, and so I'll say it again:

Please submit a patch to the stable branch so that this gets generically
fixed!  I'll happily Ack it. 

--linas
-
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: [PATCH] ata_piix: fix pio/mwdma programming

On Fri, 25 May 2007 19:16:58 +0200
Tejun Heo [EMAIL PROTECTED] wrote:

 Fix various bugs in pio/mwdma mode programming.
 
 * Control bits in the timing register wasn't cleared properly while
   programming PIO mode.
 
 * MWDMA mode programming cleared the wrong part of control bits.
 
 * MWDMA mode programming cleared udma_mask even when the controller
   doesn't support UDMA.
 
 Signed-off-by: Tejun Heo [EMAIL PROTECTED]
 Cc: Art Haas [EMAIL PROTECTED]

Acked-by: Alan Cox [EMAIL PROTECTED]

 ---
 Patch is against libata-dev#upstream.  Thanks.
 
  drivers/ata/ata_piix.c |   23 +--
  1 file changed, 17 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
 index 9c07b88..924e447 100644
 --- a/drivers/ata/ata_piix.c
 +++ b/drivers/ata/ata_piix.c
 @@ -685,8 +685,14 @@ static void piix_set_piomode (struct ata
   if (adev-class == ATA_DEV_ATA)
   control |= 4;   /* PPE enable */
  
 + /* PIO configuration clears DTE unconditionally.  It will be
 +  * programmed in set_dmamode which is guaranteed to be called
 +  * after set_piomode if any DMA mode is available.
 +  */
   pci_read_config_word(dev, master_port, master_data);
   if (is_slave) {
 + /* clear TIME1|IE1|PPE1|DTE1 */
 + master_data = 0xff0f;
   /* Enable SITRE (seperate slave timing register) */
   master_data |= 0x4000;
   /* enable PPE1, IE1 and TIME1 as needed */
 @@ -694,12 +700,14 @@ static void piix_set_piomode (struct ata
   pci_read_config_byte(dev, slave_port, slave_data);
   slave_data = (ap-port_no ? 0x0f : 0xf0);
   /* Load the timing nibble for this slave */
 - slave_data |= ((timings[pio][0]  2) | timings[pio][1])  
 (ap-port_no ? 4 : 0);
 + slave_data |= ((timings[pio][0]  2) | timings[pio][1])
 +  (ap-port_no ? 4 : 0);
   } else {
 - /* Master keeps the bits in a different format */
 - master_data = 0xccf8;
 + /* clear ISP|RCT|TIME0|IE0|PPE0|DTE0 */
 + master_data = 0xccf0;
   /* Enable PPE, IE and TIME as appropriate */
   master_data |= control;
 + /* load ISP and RCT */
   master_data |=
   (timings[pio][0]  12) |
   (timings[pio][1]  8);
 @@ -816,7 +824,7 @@ static void do_pata_set_dmamode (struct
   master_data = 0xFF4F;  /* Mask out IORDY|TIME1|DMAONLY 
 */
   master_data |= control  4;
   pci_read_config_byte(dev, 0x44, slave_data);
 - slave_data = (0x0F + 0xE1 * ap-port_no);
 + slave_data = (ap-port_no ? 0x0f : 0xf0);
   /* Load the matching timing */
   slave_data |= ((timings[pio][0]  2) | 
 timings[pio][1])  (ap-port_no ? 4 : 0);
   pci_write_config_byte(dev, 0x44, slave_data);
 @@ -828,8 +836,11 @@ static void do_pata_set_dmamode (struct
   (timings[pio][0]  12) |
   (timings[pio][1]  8);
   }
 - udma_enable = ~(1  devid);
 - pci_write_config_word(dev, master_port, master_data);
 +
 + if (ap-udma_mask) {
 + udma_enable = ~(1  devid);
 + pci_write_config_word(dev, master_port, master_data);
 + }
   }
   /* Don't scribble on 0x48 if the controller does not support UDMA */
   if (ap-udma_mask)


-- 
--
Sick of rip off UK rail fares ? Learn how to get far cheaper fares
http://zeniv.linux.org.uk/~alan/GTR/
-
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: [PATCH pata-2.6 fix queue] hpt366: don't check enablebits for HPT36x

2007-05-25 Thread Sergei Shtylyov


Linas Vepstas wrote:


Linas, Andries, Michal, cound you try this instead:



  d-enablebits[0].mask = d-enablebits[0].val = 0x10;


 It probably won't work the way it should anyway -- the secondary 
channel (and controller in this case) uses another bit in this register 
and the controllers get registered with IDE core in pair.



Setting d-enablebits[0].mask = d-enablebits[0].val = 0x10; makes
my system bootable, and so this works well enough for me.  Without this
patch, mainline 2.6.21.1 is broken, and so I'll say it again:

Please submit a patch to the stable branch so that this gets generically
fixed!  I'll happily Ack it. 


   Already done. I hope it'll be in 2.6.21.3...


--linas


WBR, Sergei
-
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

[git patches] libata fixes


And a few trivial documentation patches.

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git 
upstream-linus

to receive the following updates:

 drivers/ata/libata-scsi.c  |5 ++-
 drivers/ata/pata_artop.c   |2 +-
 drivers/ata/pata_hpt37x.c  |   27 ++---
 drivers/ata/pata_it821x.c  |3 +-
 drivers/ata/pata_scc.c |   46 ++-
 drivers/ata/pata_via.c |9 ---
 drivers/ata/sata_mv.c  |   44 ++
 drivers/ata/sata_promise.c |2 +-
 drivers/ata/sata_sis.c |2 +-
 drivers/ata/sata_via.c |3 ++
 10 files changed, 98 insertions(+), 45 deletions(-)

Alan Cox (2):
  pata: Trivia
  pata_hpt37x: Further improvements based on the IDE updates and vendor 
drivers

Jeff Garzik (4):
  [libata] sata_promise: fix flags typo
  [libata] sata_mv: add TODO list
  [libata] Fix decoding of 6-byte commands
  [libata] sata_via, pata_via: Add PCI IDs.

Tony Breeds (1):
  Fix build failure for drivers/ata/pata_scc.c

Uwe Koziolek (1):
  libata: sata_sis fixes

diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c
index 242c43e..b3900cf 100644
--- a/drivers/ata/libata-scsi.c
+++ b/drivers/ata/libata-scsi.c
@@ -1050,14 +1050,15 @@ static unsigned int ata_scsi_flush_xlat(struct 
ata_queued_cmd *qc)
 static void scsi_6_lba_len(const u8 *cdb, u64 *plba, u32 *plen)
 {
u64 lba = 0;
-   u32 len = 0;
+   u32 len;
 
VPRINTK(six-byte command\n);
 
+   lba |= ((u64)(cdb[1]  0x1f))  16;
lba |= ((u64)cdb[2])  8;
lba |= ((u64)cdb[3]);
 
-   len |= ((u32)cdb[4]);
+   len = cdb[4];
 
*plba = lba;
*plen = len;
diff --git a/drivers/ata/pata_artop.c b/drivers/ata/pata_artop.c
index 7b4810c..03b6ddd 100644
--- a/drivers/ata/pata_artop.c
+++ b/drivers/ata/pata_artop.c
@@ -97,7 +97,7 @@ static int artop6260_pre_reset(struct ata_port *ap, unsigned 
long deadline)
  * artop6260_cable_detect  -   identify cable type
  * @ap: Port
  *
- * Identify the cable type for the ARTOp interface in question
+ * Identify the cable type for the ARTOP interface in question
  */
 
 static int artop6260_cable_detect(struct ata_port *ap)
diff --git a/drivers/ata/pata_hpt37x.c b/drivers/ata/pata_hpt37x.c
index a54c174..6446735 100644
--- a/drivers/ata/pata_hpt37x.c
+++ b/drivers/ata/pata_hpt37x.c
@@ -26,7 +26,7 @@
 #include linux/libata.h
 
 #define DRV_NAME   pata_hpt37x
-#define DRV_VERSION0.6.5
+#define DRV_VERSION0.6.6
 
 struct hpt_clock {
u8  xfer_speed;
@@ -931,15 +931,6 @@ static int hpt37x_init_one(struct pci_dev *dev, const 
struct pci_device_id *id)
.udma_mask = 0x7f,
.port_ops = hpt372_port_ops
};
-   /* HPT371, 372 and friends - UDMA100 at 50MHz clock */
-   static const struct ata_port_info info_hpt372_50 = {
-   .sht = hpt37x_sht,
-   .flags = ATA_FLAG_SLAVE_POSS|ATA_FLAG_SRST,
-   .pio_mask = 0x1f,
-   .mwdma_mask = 0x07,
-   .udma_mask = 0x3f,
-   .port_ops = hpt372_port_ops
-   };
/* HPT374 - UDMA133 */
static const struct ata_port_info info_hpt374 = {
.sht = hpt37x_sht,
@@ -1098,17 +1089,21 @@ static int hpt37x_init_one(struct pci_dev *dev, const 
struct pci_device_id *id)
 *  use a 50MHz DPLL by choice
 */
unsigned int f_low, f_high;
-   int adjust;
+   int dpll, adjust;
 
-   clock_slot = 2;
+   /* Compute DPLL */
+   dpll = 2;
if (port-udma_mask  0xE0)
-   clock_slot = 3;
+   dpll = 3;
 
-   f_low = (MHz[clock_slot] * chip_table-base) / 192;
+   f_low = (MHz[clock_slot] * 48) / MHz[dpll];
f_high = f_low + 2;
+   if (clock_slot  1)
+   f_high += 2;
 
/* Select the DPLL clock. */
pci_write_config_byte(dev, 0x5b, 0x21);
+   pci_write_config_dword(dev, 0x5C, (f_high  16) | f_low);
 
for(adjust = 0; adjust  8; adjust++) {
if (hpt37x_calibrate_dpll(dev))
@@ -1124,12 +1119,12 @@ static int hpt37x_init_one(struct pci_dev *dev, const 
struct pci_device_id *id)
printk(KERN_WARNING hpt37x: DPLL did not 
stabilize.\n);
return -ENODEV;
}
-   if (clock_slot == 3)
+   if (dpll == 3)
private_data = (void *)hpt37x_timings_66;
else
private_data = (void *)hpt37x_timings_50;
 
-   printk(KERN_INFO hpt37x: Bus clock %dMHz, using DPLL.\n, 
MHz[clock_slot]);
+   printk(KERN_INFO

Re: [PATCH] ahci: disable 64bit dma on sb600

2007-05-25 Thread Bo Nygaard Bai


Tejun Heo wrote:

Bo Nygaard Bai wrote:
  

Hello!

Sorry to bug you on this.

I found this thread where you and Srihari Vijayaraghavan found a solution
to making AHCI work on SB600/AMD960G with more than 4G RAM.

As far as i can see the patch is included in the snapshot kernel:
2.6.22-rc2-git4

The code is there, but it does not seem to be active. I am still getting
the error,
and only when using more than 4G of RAM. Perhaps something when wrong
when it was merged?



Or you're seeing a different error?  Please post dmesg and cc
[EMAIL PROTECTED]

  


Ok, here we go!

Kernel build was 2.6.22-rc2-git4. Only selected libata ide support 
(CONFIG_IDE=n)


dmesg output:

Linux version 2.6.22-rc2bai ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 
(prerelease) (Debian 4.1.1-21)) #1 SMP Wed May 23 23:31:15 CEST 2007

Command line: root=/dev/mapper/server1-root ro
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 000F81A0, 0024 (r2 ATI   )
ACPI: XSDT D7EE3100, 0044 (r1 ATIASUSACPI 42302E31 AWRD0)
ACPI: FACP D7EE84C0, 00F4 (r3 ATIASUSACPI 42302E31 AWRD0)
ACPI: DSDT D7EE3280, 51D4 (r1 ATIASUSACPI 1000 MSFT  300)
ACPI: FACS D7EE, 0040
ACPI: SSDT D7EE86C0, 01C4 (r1 PTLTD  POWERNOW1  LTP1)
ACPI: MCFG D7EE8980, 003C (r1 ATIASUSACPI 42302E31 AWRD0)
ACPI: APIC D7EE8600, 0068 (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
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: 955 pages reserved
 DMA zone: 2988 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
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_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, 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
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at f100 (gap: f000:ec0)
SMP: Allowing 2 CPUs, 0 hotplug CPUs
PERCPU: Allocating 32712 bytes of per cpu data
Built 1 zonelists.  Total pages: 998340
Kernel command line: root=/dev/mapper/server1-root ro
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 32768 bytes)
Marking TSC unstable due to TSCs unsynchronized
time.c: Detected 2000.008 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes)
Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes)
Checking aperture...
CPU 0: aperture @ 800 size 32 MB
Aperture too small (32 MB)
No AGP bridge found
Your BIOS doesn't leave a aperture memory hole
Please enable the IOMMU option in the BIOS setup
This costs you 64 MB of RAM
Mapping aperture over 65536 KB of RAM @ 800
Memory: 3916940k/4718592k available (2174k kernel code, 144292k 
reserved, 1003k data, 200k init)
Calibrating delay using timer specific routine.. 4003.07 BogoMIPS 
(lpj=8006152)

Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 256
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 512K (64 bytes/line)
CPU: Physical Processor ID: 0
CPU: Processor Core ID: 0
SMP alternatives:

Re: [PATCH] ahci: disable 64bit dma on sb600

2007-05-25 Thread Bo Nygaard Bai


Bo Nygaard Bai wrote:

Tejun Heo wrote:

Bo Nygaard Bai wrote:
 

Hello!

Sorry to bug you on this.


Even more sorry now... it was my own stupid mistake!

Had mixed up the kernels. Hope I didn't waste too much of your time. :-[

Thanks, for all the good work!

/Bo Bai
-
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: [git patches] libata fixes

2007-05-25 Thread Mikael Pettersson

On Fri, 25 May 2007 18:03:07 -0400, Jeff Garzik wrote:
Jeff Garzik (4):
  [libata] sata_promise: fix flags typo
...
--- a/drivers/ata/sata_promise.c
+++ b/drivers/ata/sata_promise.c
@@ -297,7 +297,7 @@ static const struct ata_port_info pdc_port_info[] = {
 
   /* board_2057x_pata */
   {
-  .flags  = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS,
+  .flags  = PDC_COMMON_FLAGS | ATA_FLAG_SLAVE_POSS |
 PDC_FLAG_GEN_II,
   .pio_mask   = 0x1f, /* pio0-4 */
   .mwdma_mask = 0x07, /* mwdma0-2 */

Acked-by: Mikael Pettersson [EMAIL PROTECTED]

Good catch. This typo would have prevented pdc_host_intr()
from detecting GEN_II-specific errors on the PATA port.
-
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: sata_mv error recovery issues


Lennert Buytenhek wrote:

(please CC on replies, I'm not subscribed to linux-ide@)

Hi,

sata_mv (driving two 8-port Supermicro AOC-SAT2-MV8 PCI-X adapters) in
2.6.18-1.2747.el5 (RHEL/CentOS 5 beta kernel) didn't respond too well
to one of the attached disks experiencing what seems to be a head crash.

Apr  4 13:52:20 duality kernel: ata5: Entering mv_eng_timeout
Apr  4 13:52:20 duality kernel: mmio_base f898 ap f7b442dc qc f7b44cf8 
scsi_cmnd e719ee00 cmnd e719ee38
Apr  4 13:52:30 duality kernel: ata5: no sense translation for status: 0x40
Apr  4 13:52:30 duality kernel: ata5: translated ATA stat/err 0x40/00 to SCSI 
SK/ASC/ASCQ 0xb/00/00
Apr  4 13:52:30 duality kernel: ata5: status=0x40 { DriveReady }
Apr  4 13:52:30 duality kernel: sd 4:0:0:0: SCSI error: return code = 0x0802
Apr  4 13:52:30 duality kernel: sde: Current: sense key: Aborted Command
Apr  4 13:52:30 duality kernel: Additional sense: No additional sense 
information
Apr  4 13:52:30 duality kernel: end_request: I/O error, dev sde, sector 
684432191

At this point, the machine got into an endless loop where it would
completely freeze for a couple of seconds every minute or so (busy wait
in kernel space?), during which time it wouldn't respond to keyboard
input, ping packets or any other input.

Every time when it unfroze after being frozen for a couple of seconds,
it would spit out a similar mv_eng_timeout message as above, and it
would reply to the ping packets sent to it while it was frozen (i.e. a
sudden burst of ping reply packets with ping times of 1ms, 1001ms,
2001ms, 3001ms, 4001ms, 5001ms etc), which makes me think it was just
spinning in kernelspace somewhere.

Apr  4 13:56:02 duality kernel: BUG: soft lockup detected on CPU#3!
Apr  4 13:56:02 duality kernel:  [c04051ba] dump_trace+0x69/0x1af
Apr  4 13:56:02 duality kernel:  [c0405318] show_trace_log_lvl+0x18/0x2c
Apr  4 13:56:02 duality kernel:  [c04058cc] show_trace+0xf/0x11
Apr  4 13:56:02 duality kernel:  [c04059c9] dump_stack+0x15/0x17
Apr  4 13:56:02 duality kernel:  [c044d4da] softlockup_tick+0xa6/0xb4
Apr  4 13:56:02 duality kernel:  [c042e32a] update_process_times+0x39/0x5c
Apr  4 13:56:02 duality kernel:  [c04188d4] smp_apic_timer_interrupt+0x5c/0x64
Apr  4 13:56:02 duality kernel:  [c0404a8b] apic_timer_interrupt+0x1f/0x24
Apr  4 13:56:02 duality kernel: DWARF2 unwinder stuck at 
apic_timer_interrupt+0x1f/0x24
Apr  4 13:56:02 duality kernel: Leftover inexact backtrace:
Apr  4 13:56:02 duality kernel:  [c0610468] _spin_unlock_irqrestore+0x8/0x9
Apr  4 13:56:02 duality kernel:  [f88cea77] mv_eng_timeout+0xac/0x105 
[sata_mv]
Apr  4 13:56:02 duality kernel:  [f888728d] scsi_error_handler+0x0/0x9c7 
[scsi_mod]
Apr  4 13:56:02 duality kernel:  [f88f8fdc] ata_scsi_error+0x3c6/0x4be 
[libata]
Apr  4 13:56:02 duality kernel:  [f8884217] __scsi_iterate_devices+0x50/0x58 
[scsi_mod]
Apr  4 13:56:02 duality kernel:  [f888728d] scsi_error_handler+0x0/0x9c7 
[scsi_mod]
Apr  4 13:56:02 duality kernel:  [f888732c] scsi_error_handler+0x9f/0x9c7 
[scsi_mod]
Apr  4 13:56:02 duality kernel:  [c041e4f6] complete+0x2b/0x3d
Apr  4 13:56:02 duality kernel:  [f888728d] scsi_error_handler+0x0/0x9c7 
[scsi_mod]
Apr  4 13:56:02 duality kernel:  [c0436620] kthread+0xc0/0xec
Apr  4 13:56:02 duality kernel:  [c0436560] kthread+0x0/0xec
Apr  4 13:56:02 duality kernel:  [c0404d63] kernel_thread_helper+0x7/0x10
Apr  4 13:56:02 duality kernel:  ===

All I/O to the RAID array that this disk was a member of (12 disk 6TB
software RAID6 array) froze completely.  It did mark the broken disk
failed, but didn't recover from the failure.  I had to reboot the box
with the power switch, as '/sbin/reboot -f' via ssh would also get
stuck in D state.

Any other info I can give?  I still have the crashed disk in case
anyone wants me to do some tests with it..


(going through old email that might have not received a reply)

Upstream sata_mv error handling is pretty shabby.

There is a TODO list in the (as-of-X-hours-ago) current git tree, at the 
top of sata_mv.c, that gives you some sort of idea.


There is also preliminary new-EH code in libata-dev.git#mv-eh that you 
are encouraged to test.  It's not upstream because there are still some 
reported problems, but it much improved over what is in upstream.


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

[PATCH, RFT, v4] sata_mv: convert to new EH