Re: Serial ATA does not find partitions (Hitachi HD, new? ATI controller) where old SATA works
Hernan Gustavo Solari wrote: Tejun netconsole, pritty nice debunging system... but (yes, there is always a but) it does not get to run. the method was well implemented, adding the acpi=off it sends the information to the receiving machine (I can even see passing a netconsole probing message in the machine under testing), but without turning off acpi it does not reach the point of loading and, consequently, it does not send a byte to the receiving machine. Hence, result: empty output. Hmmm.. Are netconsole support and network driver built into the kernel? -- 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: ICH9 2 port SATA controller port map?
Gaston, Jason D wrote: What is the difference between NA and RV? If the controller only has access to 2 ports, does it matter which I set the nonexistent port values to in the map? NA is used for unimplemented ports of a valid configuration while RV is used to mark invalid MAP value. So, NA should be mixed with P[0-3] while RV can't be mixed with any other values. -- Tejun When you say can't be mixed do you mean I should not have [P0 RV P1 RV] on the same line? If that is the case, then I assume my only choice, for the 2 port controller (physically ports 5 6) would be [P0 NA P1 NA]. Yeap, that's correct. -- 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: PMP Patchset against 2.6.22.latest 2.6.23.latest
Daniel Schroeder wrote: Hello Tejun, i am stuck with 2.6.22.1 because this is the latest version of your PMP patchset...this is perfectly working but i can not apply these set against newer versions of the kernel...could you update your homepage or post a howto/message/link for instructions to get the patchset against 2.6.22.latest and 2.6.23.latest? I'll update the patch series. 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: Promise SATA300 TX4: errors, oops in ext3 code
Alexander Sabourenkov schrieb: Have you checked your memory already (memtest86)? [...] Again... sounds like bad memory to me. Nightly memtest86 run : 11 hours, 23 passes, 0 errors. Okay, I have no idea about any bugs there. You have several options: Find a 100% working vanilla kernel for your problem (minimal configuration, skip i.e. the sound stuff, ...). And then git bisect with a known bad kernel. Same thing in hardware: move components (Controllers + HDD) to/from a working machine and verify... Regards, Clemens Koller __ RD Imaging Devices Anagramm GmbH Rupert-Mayer-Straße 45/1 Linhof Werksgelände D-81379 München Tel.089-741518-50 Fax 089-741518-19 http://www.anagramm-technology.com - 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] blacklist NCQ on Seagate Barracuda ST380817AS
Hello, Mark Lord wrote: Mmm.. $66 for open box. But the drive itself has been discontinued by Seagate, Couldn't find any in SUSE and I don't think I can't find any vendor who still carries the drive here. and once claimed to be World's first SATA desktop drive with NCQ.. Probably buggy firmware after all. Yeah, World's first is a pretty good clue indicating broken. Blacklisting it seems like a good idea after all. 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: Promise SATA300 TX4: errors, oops in ext3 code
Clemens Koller wrote: Okay, I have no idea about any bugs there. You have several options: Find a 100% working vanilla kernel for your problem (minimal configuration, skip i.e. the sound stuff, ...). And then git bisect with a known bad kernel. I'm afraid there is no 100% working kernel. Problems were reported as far back as 2.6.11, and I never found a single thread in mailing lists ending with problem solved (not counting PSU and thermal issues). Same thing in hardware: move components (Controllers + HDD) to/from a working machine and verify... Unfortunately right now I have no yet-untested machine - both I have show same problems. Time permitting I'll test 2.6.23 kernel, libata-dev branch, SATA300/SATA150 modes and agressive card cooling as you suggested in your other email and document all this on a separate page or maybe a wiki. -- ./lxnt - 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: Serial ATA does not find partitions (Hitachi HD, new? ATI controller) where old SATA works
netconsole, pritty nice debunging system... but (yes, there is always a but) it does not get to run. the method was well implemented, adding the acpi=off it sends the information to the receiving machine (I can even see passing a netconsole probing message in the machine under testing), but without turning off acpi it does not reach the point of loading and, consequently, it does not send a byte to the receiving machine. Hence, result: empty output. Hmmm.. Are netconsole support and network driver built into the kernel? yes, they are Hernan -- Hernán Gustavo Solari, [EMAIL PROTECTED], http://www.df.uba.ar/~solari - 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: [smartmontools-support] sata_sil24 with port multiplier
Jon: always nice when computers act like finite-state machines, not like incomprehensible organic devices. Tejun: thanks again. Cheers, Bruce On Sat, 29 Sep 2007, Jon Chelton wrote: Thanks Bruce and Tejun, I have replaced the hot swap drive tray of the drive in question, rebooted and reinstalled the latest version of smartmontools. So far I have read and wrote about 50GB of data to the raid array over the last 18 hours with smartd running and have not seen any kernel error messages. Looks like the interconnect was at fault. Thanks again for the help, Jon -Original Message- From: Bruce Allen [mailto:[EMAIL PROTECTED] Sent: Friday, September 28, 2007 9:48 PM To: Tejun Heo Cc: Jon Chelton; Bruce Allen; Smartmontools Mailing List; linux-ide@vger.kernel.org Subject: Re: sata_sil24 with port multiplier All errors are interface CRC errors reported by device on FPDMA_WRITE. It doesn't seem to have anything to do with SMART. In all cases, SError DIAG is reporting handshake error too (R_ERR received). I'm fairly sure these were actual hardware problems. You don't have to pay too much attention unless it happens repeatedly. Good cure for the problem is probably to re-seat the harddrive. Jon: as Tejun says, the ICRC errors indicate a problem with the data cabling or connections between the drive and the controller. Replug, clean, examine (and perhaps replace) SATA cables and/or connectors. The SMART error log (smartctl -L) might also show entries for the ICRC errors (with timestamps that might be useful). Bruce, I don't think this is SMART related. Sorry about the noise. Thanks. Tejun: thank you again, no worries, and definitely no apologies needed! Cheers, Bruce - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Smartmontools-support mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/smartmontools-support - 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 4/4] hpt366: MWDMA filter for SATA cards (take 2)
Bartlomiej Zolnierkiewicz wrote:
The Marvell bridge chips used on HighPoint SATA cards do not seem to support
the MWDMA modes (at least that caould be seen in their so-called drivers :-),
so the driver needs to account for this -- to achieve this:
- add mdma_filter() method from the original patch by Bartlomiej Zolnierkewicz
with his consent,
also adding the method callout to ide_rate_filter();
Ugh, forgot to remove this part -- it's no longer true.
- install the method for all chips to only return empty mask if a SATA drive
is detected on HPT372{AN]/374 chips...
Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED]
applied
Thanks,
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
Re: [PATCH 1/15] ali14xx: fix deadlock on error handling
Bartlomiej Zolnierkiewicz wrote: Stop abusing ide_lock lock by switching to a private locking. Fixes same issue as fixed by Alan Cox in atiixp host driver with Has been also fixed in the piix driver. commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627. Heh, I've looked hard at the code trying to understand how this can happen, and was unable to figure out. Probably was not hard enough... Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, 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
Re: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Tejun Heo wrote: Jeff Garzik wrote: Mark Lord wrote: Linux kernel development is supposed to happen incrementally nowadays. Get a nice working solution in place, and then enhance/tune it. It's not about enhancing and tuning. It's about me (and/or James B) having to __undo__ the current code, just to get things working on an entire class of SATA-capable controllers out in the field. Hmmm... Simpy not setting ATA_FLAG_PMP isn't enough? The point was that I was going to turn on PMP support for SAS controllers in 2.6.24 to coincide with the merge, but now cannot without fixing things. 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 3/15] qd65xx: fix deadlock on error handling
Bartlomiej Zolnierkiewicz wrote:
Stop abusing ide_lock lock (switch to a private locking).
Fixes same issue as fixed by Alan Cox in atiixp host driver with
commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Index: b/drivers/ide/legacy/qd65xx.c
===
--- a/drivers/ide/legacy/qd65xx.c
+++ b/drivers/ide/legacy/qd65xx.c
@@ -89,13 +89,15 @@
static int timings[4]={-1,-1,-1,-1}; /* stores current timing for each timer */
+static DEFINE_SPINLOCK(qd65xx_lock);
+
static void qd_write_reg (u8 content, unsigned long reg)
{
unsigned long flags;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(qd65xx_lock, flags);
outb(content,reg);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(qd65xx_lock, flags);
}
static u8 __init qd_read_reg (unsigned long reg)
@@ -103,9 +105,9 @@ static u8 __init qd_read_reg (unsigned l
unsigned long flags;
u8 read;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(qd65xx_lock, flags);
read = inb(reg);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(qd65xx_lock, flags);
return read;
}
I don't see why all the locking above is needed at all -- isn't these
atomic functions? :-/
@@ -301,16 +303,15 @@ static void qd6580_set_pio_mode(ide_driv
static int __init qd_testreg(int port)
{
- u8 savereg;
- u8 readreg;
unsigned long flags;
+ u8 savereg, readreg;
- spin_lock_irqsave(ide_lock, flags);
+ spin_lock_irqsave(qd65xx_lock, flags);
savereg = inb_p(port);
outb_p(QD_TESTVAL, port); /* safe value */
readreg = inb_p(port);
outb(savereg, port);
- spin_unlock_irqrestore(ide_lock, flags);
+ spin_unlock_irqrestore(qd65xx_lock, flags);
if (savereg == QD_TESTVAL) {
printk(KERN_ERR Outch ! the probe for qd65xx isn't reliable
!\n);
Heh, 486 with VLB hardly needed spinlocks at all... although there *were*
486 SMP machines -- with external LAPICs.
MBR, 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
Re: [PATCH 9/15] cs5530: remove needless ide_lock taking
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, 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
Re: [PATCH 5/15] slc90e66: fix deadlock on error handling
Bartlomiej Zolnierkiewicz wrote: * Stop abusing ide_lock lock (switch to a private locking). Fixes same issue as fixed by Alan Cox in atiixp host driver with commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627. ... and in the piix as well. Since I failed to see what could lead to this in the kernel.org code, I haven't carried the fix to slc90e66... * Bump driver version. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, 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
Re: [PATCH 3/15] qd65xx: fix deadlock on error handling
Sergei Shtylyov wrote:
Bartlomiej Zolnierkiewicz wrote:
Stop abusing ide_lock lock (switch to a private locking).
Fixes same issue as fixed by Alan Cox in atiixp host driver with
commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627.
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Index: b/drivers/ide/legacy/qd65xx.c
===
--- a/drivers/ide/legacy/qd65xx.c
+++ b/drivers/ide/legacy/qd65xx.c
@@ -89,13 +89,15 @@
static int timings[4]={-1,-1,-1,-1}; /* stores current timing for
each timer */
+static DEFINE_SPINLOCK(qd65xx_lock);
+
static void qd_write_reg (u8 content, unsigned long reg)
{
unsigned long flags;
-spin_lock_irqsave(ide_lock, flags);
+spin_lock_irqsave(qd65xx_lock, flags);
outb(content,reg);
-spin_unlock_irqrestore(ide_lock, flags);
+spin_unlock_irqrestore(qd65xx_lock, flags);
}
static u8 __init qd_read_reg (unsigned long reg)
@@ -103,9 +105,9 @@ static u8 __init qd_read_reg (unsigned l
unsigned long flags;
u8 read;
-spin_lock_irqsave(ide_lock, flags);
+spin_lock_irqsave(qd65xx_lock, flags);
read = inb(reg);
-spin_unlock_irqrestore(ide_lock, flags);
+spin_unlock_irqrestore(qd65xx_lock, flags);
return read;
}
I don't see why all the locking above is needed at all -- isn't these
atomic functions? :-/
Agreed.
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: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Jeff Garzik wrote: Tejun Heo wrote: Jeff Garzik wrote: Mark Lord wrote: Linux kernel development is supposed to happen incrementally nowadays. Get a nice working solution in place, and then enhance/tune it. It's not about enhancing and tuning. It's about me (and/or James B) having to __undo__ the current code, just to get things working on an entire class of SATA-capable controllers out in the field. Hmmm... Simpy not setting ATA_FLAG_PMP isn't enough? The point was that I was going to turn on PMP support for SAS controllers in 2.6.24 to coincide with the merge, but now cannot without fixing things. So, don't. Just a few days ago PMP was slated to not be enabled for *any* controllers until 2.6.25 or so. Now we have it a release early, for all but SAS. Cheers - 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 15/15] ide: remove stale comments from ide-taskfile.c
Bartlomiej Zolnierkiewicz wrote: Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, 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
Re: [PATCH 10/15] ide: enhance ide_setup_pci_noise()
Bartlomiej Zolnierkiewicz wrote: * Print PCI device Vendor ID, Device ID and revision in ide_setup_pci_noise(). * Remove no longer needed PCI device revision printing from ide_setup_pci_controller(). Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, 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
Re: [PATCH 14/15] ide: remove dead code from ide_driveid_update()
Bartlomiej Zolnierkiewicz wrote: * Remove dead code from ide_driveid_update(). While at it: * Remove useless comment. * s/HWIF(drive)/drive-hwif/ Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] Acked-by: Sergei Shtylyov [EMAIL PROTECTED] MBR, 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
Re: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Mark Lord wrote: Jeff Garzik wrote: Tejun Heo wrote: Jeff Garzik wrote: Mark Lord wrote: Linux kernel development is supposed to happen incrementally nowadays. Get a nice working solution in place, and then enhance/tune it. It's not about enhancing and tuning. It's about me (and/or James B) having to __undo__ the current code, just to get things working on an entire class of SATA-capable controllers out in the field. Hmmm... Simpy not setting ATA_FLAG_PMP isn't enough? The point was that I was going to turn on PMP support for SAS controllers in 2.6.24 to coincide with the merge, but now cannot without fixing things. So, don't. Just a few days ago PMP was slated to not be enabled for *any* controllers until 2.6.25 or so. Now we have it a release early, for all but SAS. A few days before that, both PMP and SAS /were/ slated for 2.6.24, and after I fix the design problems, they will be again. One way or another, upstream will /not/ be doing polling PMP in 2.6.24. 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 9/15] cs5530: remove needless ide_lock taking
- spin_lock_irqsave(ide_lock, flags); - /* all CPUs (there should only be one CPU with this chipset) */ - NAK What about pre-emptible kernels. Put in a private lock. 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: [PATCH 1/15] ali14xx: fix deadlock on error handling
On Tue, 02 Oct 2007 16:46:28 +0400 Sergei Shtylyov [EMAIL PROTECTED] wrote: Bartlomiej Zolnierkiewicz wrote: Stop abusing ide_lock lock by switching to a private locking. Fixes same issue as fixed by Alan Cox in atiixp host driver with Has been also fixed in the piix driver. commit 6c5f8cc33eb2e10b6ab788bbe259fc142a068627. Heh, I've looked hard at the code trying to understand how this can happen, and was unable to figure out. Probably was not hard enough... The old IDE code timer, error handling and interrupt paths all race each other. Anything can happen including this. The proper fix is to rewrite the error handling but it was easier to port the drivers to working error handling instead - hence libata PATA 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: [PATCH] blacklist NCQ on Seagate Barracuda ST380817AS
On Tue, 02 Oct 2007 18:19:14 +0900 Tejun Heo [EMAIL PROTECTED] wrote: Yeah, World's first is a pretty good clue indicating broken. Blacklisting it seems like a good idea after all. OT: I cannot test anything NCQ related for a while because the Intel Mobo departed yesterday, so I'm on a different board without NCQ support ;) -- Paolo Ornati Linux 2.6.23-rc8generic-ga64314e6 on x86_64 - 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_hpt3x2n: Clean up DPLL stuff
On Mon, 01 Oct 2007 17:12:03 +0400 Sergei Shtylyov [EMAIL PROTECTED] wrote: Hello. Alan Cox wrote: Nobody commented when I asked for review earlier so it must be ok 8) It's not that I've seen this before so it must be ok 8) Not by me at least, so let me NAK it. 8-) Lets stick it in -mm to be sure Now let's unstick it. :-) Ok I shall revisit that. Andrew please drop - 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: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Polling PMP 2.6.24 is completely unacceptable. It screws the 2.6.24 SAS driver releases out of PMP. No PMP in 2.6.24 screws PMP users, who outnumber SAS users by a few thousand to one I suspect. - 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_hpt3x2n: Clean up DPLL stuff
Alan Cox wrote: On Mon, 01 Oct 2007 17:12:03 +0400 Sergei Shtylyov [EMAIL PROTECTED] wrote: Hello. Alan Cox wrote: Nobody commented when I asked for review earlier so it must be ok 8) It's not that I've seen this before so it must be ok 8) Not by me at least, so let me NAK it. 8-) Lets stick it in -mm to be sure Now let's unstick it. :-) Ok I shall revisit that. Andrew please drop As I noted at the time of posting, this is in libata-dev.git#for-testing (and thus propagated to -mm via that route). Consider it dropped, from my end. 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: Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Alan Cox wrote: Polling PMP 2.6.24 is completely unacceptable. It screws the 2.6.24 SAS driver releases out of PMP. No PMP in 2.6.24 screws PMP users, who outnumber SAS users by a few thousand to one I suspect. no-PMP-in-2.6.24 is not happening, so that's rather irrelevant. 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] Asynchronous scan support for libata
Matthew Wilcox wrote: Last December, I posted this: http://lwn.net/Articles/213635/ Here's an updated version. It shaves 5 seconds off boot time on my configuration (qla2xxx, emulex, two ata_piix, dual fusion), but could save more or less on other setups. I think I can remove the 'sync' argument and code from ata_scsi_scan_host() now, but wanted to send out this update today. --- Some of the drivers (AHCI was mentioned to me as a culprit) take a long time to discover all the devices attached to them. Even for ones which are relatively quick, if you put a lot of them in a machine, it will take a long time in aggregate. This can be fixed by adding support for asynchronous scsi scans, which causes the time-consuming portions of initialisation to take place in threads. Signed-off-by: Matthew Wilcox [EMAIL PROTECTED] Did you look at SATA alone? Since SATA does its own scan asynchronously from SCSI itself, doing this seems of little value. This patch doesn't change AHCI scanning at all, for example. Quite willing to be convinced otherwise, though... 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 more device IDs for supporting ATI SB800 SATA controller
su henry wrote: From: henry su[EMAIL PROTECTED] ATI/AMD SB800 shares some device IDs with SB700, and SB800 adds two more device IDs:0x4394,0x4395. Signed-off-by: henry su[EMAIL PROTECTED] This patch was already applied, on September 20th. It's already upstream in the official Linux kernel, too: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Regards, 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 #upstream-fixes] ata_piix: add another TECRA M3 entry to broken suspend list
Tejun Heo wrote: There's a different version of DMI table for TECRA M3 where it has proper vendor and product name entry. Add the entry to the broken suspend list. Angus Turnbull reported and provided initial patch. Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Angus Turnbull [EMAIL PROTECTED] --- drivers/ata/ata_piix.c |7 +++ 1 file changed, 7 insertions(+) applied - 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 -mm] libata: add human-readable error value decoding v3
Robert Hancock wrote:
This adds human-readable decoding of the ATA status and error registers
(similar to what drivers/ide does) as well as the SATA Serror register to
libata error handling output. This prevents the need to pore through
standards documents to figure out the meaning of the bits in these
registers when looking at error reports. Some bits that drivers/ide
decoded are not decoded here, since the bits are either command-dependent
or obsolete, and properly parsing them would add too much complexity.
Signed-off-by: Robert Hancock [EMAIL PROTECTED]
---
Rebased to apply to 2.6.23-rc1-mm2.
I'm applying this manually sorry it took so long, the asymmetry of
{DRDY } bugged me, so I did a few cleanups.
-
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/7] sata_promise: pdc_freeze() semantic change
Albert Lee wrote: After checking the current implementations of freeze()/thaw(), it seems only pdc_freeze() does more than simple irq masking. Remove the DMA stop code from pdc_freeze(). Signed-off-by: Albert Lee [EMAIL PROTECTED] --- diff -Nrup 01_remove_leftover_irqon/drivers/ata/sata_promise.c 02_sata_pdc_freeze/drivers/ata/sata_promise.c --- 01_remove_leftover_irqon/drivers/ata/sata_promise.c 2007-07-07 09:58:55.0 +0800 +++ 02_sata_pdc_freeze/drivers/ata/sata_promise.c 2007-07-07 10:39:22.0 +0800 @@ -578,7 +578,6 @@ static void pdc_freeze(struct ata_port * tmp = readl(mmio + PDC_CTLSTAT); tmp |= PDC_IRQ_DISABLE; - tmp = ~PDC_DMA_ENABLE; writel(tmp, mmio + PDC_CTLSTAT); readl(mmio + PDC_CTLSTAT); /* flush */ Two comments: 1) I do not think it safe to simply remove this. Have you verified that pdc_reset_port() without a disabled DMA engine works 100%? At the very least I would say to -move- this code, rather the deleting it. 2) It was put there to disable the DMA engine at our first opportunity. For some errors we really should take some preliminary port/DMA-disable actions in the interrupt handler, before kicking off EH and waiting to be scheduled in process context. 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] ahci: Add MCP79 support to AHCI driver
Peer Chen wrote:
Code change, remove some Device IDs.
Signed-off-by: Peer Chen [EMAIL PROTECTED]
---
--- linux-2.6.23-rc7/drivers/ata/ahci.c.orig2007-09-20 11:01:55.0
-0400
+++ linux-2.6.23-rc7/drivers/ata/ahci.c 2007-09-24 10:08:03.0 -0400
@@ -472,6 +472,14 @@ static const struct pci_device_id ahci_p
{ PCI_VDEVICE(NVIDIA, 0x0ad9), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0ada), board_ahci },/* MCP77 */
{ PCI_VDEVICE(NVIDIA, 0x0adb), board_ahci },/* MCP77 */
+ { PCI_VDEVICE(NVIDIA, 0x0ab8), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0ab9), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0aba), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0abb), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0abc), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0abd), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0abe), board_ahci },/* MCP79 */
+ { PCI_VDEVICE(NVIDIA, 0x0abf), board_ahci },/* MCP79 */
applied
-
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]
Alan Cox wrote:
Correct handling of SRST reset sequences. After an SRST it is undefined
whether the drive has gone back to PIO0. In order to talk safely we should
talk slowly and carefully until we know.
Thus when we do the reset if the controller has a pio setup method we call
it to flip back to PIO 0 and a known state. After the reset completes the
identify will then be done at the safe speed and the drive/controller will
pick suitable faster modes and reconfigure the controller to these timings.
As a side effect it means we force the controller to PIO 0 as we bring it
up which fixes funnies on a few systems where the BIOS firmware leaves us
in an interesting choice of modes, or embedded boxes with no firmware which
come up in random states.
For smart controllers there is nothing to do - they know about this internally.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c
linux-2.6.23rc3-mm1/drivers/ata/libata-core.c
--- linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c 2007-08-22
17:23:00.0 +0100
+++ linux-2.6.23rc3-mm1/drivers/ata/libata-core.c 2007-08-22
18:17:31.321738376 +0100
@@ -3163,6 +3191,8 @@
unsigned long deadline)
{
struct ata_ioports *ioaddr = ap-ioaddr;
+ struct ata_device *dev;
+ int i = 0;
DPRINTK(ata%u: bus reset via SRST\n, ap-print_id);
@@ -3173,6 +3203,25 @@
udelay(20); /* FIXME: flush */
iowrite8(ap-ctl, ioaddr-ctl_addr);
+ /* If we issued an SRST then an ATA drive (not ATAPI)
+* may have changed configuration and be in PIO0 timing. If
+* we did a hard reset (or are coming from power on) this is
+* true for ATA or ATAPI. Until we've set a suitable controller
+* mode we should not touch the bus as we may be talking too fast.
+*/
+
+ ata_link_for_each_dev(dev, ap-link)
+ dev-pio_mode = XFER_PIO_0;
+
+ /* If the controller has a pio mode setup function then use
+ it to set the chipset to rights. Don't touch the DMA setup
+ as that will be dealt with when revalidating */
+ if (ap-ops-set_piomode) {
+ ata_link_for_each_dev(dev, ap-link)
+ if (devmask (1 i++))
+ ap-ops-set_piomode(ap, dev);
+ }
+
Should this be queued for 2.6.24?
The note I have on this is low priority, make sure it gets testing in
-mm first
-
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]
Should this be queued for 2.6.24? The note I have on this is low priority, make sure it gets testing in -mm first Its been tested without any reports. There are two things it sorts out #1 non x86 systems with firmware that doesn't init the chip into PIO0 (not many as most chips power up in pio0) #2 A few obscure cases where we error and then can't recover an ATA drive as we are talking PIO4 at it and its in PIO0 so we are burbling too fast (the other way around is of course ok) 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: PMP Patchset against 2.6.22.latest 2.6.23.latest
Jeff Garzik wrote: Daniel Schroeder wrote: i am stuck with 2.6.22.1 because this is the latest version of your PMP patchset...this is perfectly working but i can not apply these set against newer versions of the kernel...could you update your homepage or post a howto/message/link for instructions to get the patchset against 2.6.22.latest and 2.6.23.latest? Once you obtain the 'master' and 'upstream' branches of git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git you may simply do git diff master..upstream patch git-clone git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git master git diff master..origin/upstream patch worked for me... to obtain the diff against current 2.6.23-rcX (what will be 2.6.23 release). Jeff thx Daniel - 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
pata_acpi resend?
As mentioned at the kernel summit... requesting that somebody send me a single patch that adds pata_acpi to the kernel (with all pata_acpi fixes and updates rolled into that patch). 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]
Alan Cox wrote:
Correct handling of SRST reset sequences. After an SRST it is undefined
whether the drive has gone back to PIO0. In order to talk safely we should
talk slowly and carefully until we know.
Thus when we do the reset if the controller has a pio setup method we call
it to flip back to PIO 0 and a known state. After the reset completes the
identify will then be done at the safe speed and the drive/controller will
pick suitable faster modes and reconfigure the controller to these timings.
As a side effect it means we force the controller to PIO 0 as we bring it
up which fixes funnies on a few systems where the BIOS firmware leaves us
in an interesting choice of modes, or embedded boxes with no firmware which
come up in random states.
For smart controllers there is nothing to do - they know about this internally.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
diff -u --new-file --recursive --exclude-from /usr/src/exclude
linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c
linux-2.6.23rc3-mm1/drivers/ata/libata-core.c
--- linux.vanilla-2.6.23rc3-mm1/drivers/ata/libata-core.c 2007-08-22
17:23:00.0 +0100
+++ linux-2.6.23rc3-mm1/drivers/ata/libata-core.c 2007-08-22
18:17:31.321738376 +0100
@@ -3163,6 +3191,8 @@
unsigned long deadline)
{
struct ata_ioports *ioaddr = ap-ioaddr;
+ struct ata_device *dev;
+ int i = 0;
DPRINTK(ata%u: bus reset via SRST\n, ap-print_id);
@@ -3173,6 +3203,25 @@
udelay(20); /* FIXME: flush */
iowrite8(ap-ctl, ioaddr-ctl_addr);
+ /* If we issued an SRST then an ATA drive (not ATAPI)
+* may have changed configuration and be in PIO0 timing. If
+* we did a hard reset (or are coming from power on) this is
+* true for ATA or ATAPI. Until we've set a suitable controller
+* mode we should not touch the bus as we may be talking too fast.
+*/
+
+ ata_link_for_each_dev(dev, ap-link)
+ dev-pio_mode = XFER_PIO_0;
+
+ /* If the controller has a pio mode setup function then use
+ it to set the chipset to rights. Don't touch the DMA setup
+ as that will be dealt with when revalidating */
+ if (ap-ops-set_piomode) {
+ ata_link_for_each_dev(dev, ap-link)
+ if (devmask (1 i++))
+ ap-ops-set_piomode(ap, dev);
+ }
+
/* wait a while before checking status */
ata_wait_after_reset(ap, deadline);
ACK. Requesting a patch that applies to libata-dev.git#upstream.
-
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: sil24 PMP works with ST3500641AS but not HDS721010KLA330
On Tue, Oct 02, 2007 at 10:04:45AM -0700, Marc MERLIN wrote: Howdy, I've had a system with 2.6.22.1 for a while, running 10 drives behind a PMP on a sil24 card with no problems. I forgot a couple of details: the PMP is a sil 3726CB the sil24 card is a 3124 Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems security what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ - 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 patch] libata fix
Make another laptop's suspend work.
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/ata_piix.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
Tejun Heo (1):
ata_piix: add another TECRA M3 entry to broken suspend list
diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c
index 3b8bf18..6996eb5 100644
--- a/drivers/ata/ata_piix.c
+++ b/drivers/ata/ata_piix.c
@@ -921,6 +921,13 @@ static int piix_broken_suspend(void)
{
static struct dmi_system_id sysids[] = {
{
+ .ident = TECRA M3,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
+ DMI_MATCH(DMI_PRODUCT_NAME, TECRA M3),
+ },
+ },
+ {
.ident = TECRA M5,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, TOSHIBA),
-
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
sil24 PMP works with ST3500641AS but not HDS721010KLA330
Howdy, I've had a system with 2.6.22.1 for a while, running 10 drives behind a PMP on a sil24 card with no problems. Recently, I swapped 5 250GB drives with 5 TB drives. The 5 TB drives eventually get detected, but do not work reliably. Details are below. This is all on 2.6.22.1-libata-tj-20070803. I noticed that 20070808 is out, but it says it fixed NCQ over PMP, and NCQ was working fine with my 500GB drives, so I'm not sure it's that. I'll try upgrading, but I'm pasting my current info below in case there are other things I should try Thanks Marc At boot time, the good (500GB) drives give: ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata4.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x9/0x9 ata4.00: hard resetting link ata4.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.01: hard resetting link ata4.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.02: hard resetting link ata4.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.03: hard resetting link ata4.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.04: hard resetting link ata4.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata4.05: hard resetting link ata4.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata4.00: ATA-7: ST3500641AS, 3.AAE, max UDMA/133 ata4.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32) ata4.00: configured for UDMA/100 ata4.01: ATA-7: ST3500641AS, 3.AAE, max UDMA/133 ata4.01: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata4.01: configured for UDMA/100 ata4.02: ATA-7: ST3500641AS, 3.AAE, max UDMA/133 ata4.02: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata4.02: configured for UDMA/100 ata4.03: ATA-7: ST3500641AS, 3.AAD, max UDMA/133 ata4.03: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata4.03: configured for UDMA/100 ata4.04: ATA-7: ST3500641AS, 3.AAD, max UDMA/133 ata4.04: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32) ata4.04: configured for UDMA/100 ata4: EH complete (...) PM: Adding info for No Bus:target4:0:0 scsi 4:0:0:0: Direct-Access ATA ST3500641AS 3.AA PQ: 0 ANSI: 5 PM: Adding info for scsi:4:0:0:0 sd 4:0:0:0: [sdh] 976773168 512-byte hardware sectors (500108 MB) sd 4:0:0:0: [sdh] Write Protect is off sd 4:0:0:0: [sdh] Mode Sense: 00 3a 00 00 sd 4:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 4:0:0:0: [sdh] 976773168 512-byte hardware sectors (500108 MB) sd 4:0:0:0: [sdh] Write Protect is off sd 4:0:0:0: [sdh] Mode Sense: 00 3a 00 00 sd 4:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sdh: sdh1 sd 4:0:0:0: [sdh] Attached SCSI disk The new drives give: ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata3.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x9/0x9 ata3.00: hard resetting link ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.01: hard resetting link ata3.01: softreset failed (timeout) ata3.01: hard resetting link ata3.01: COMRESET failed (errno=-5) ata3.01: reset failed, giving up ata3.15: hard resetting link ata3.15: softreset failed (timeout) ata3.15: hard resetting link ata3.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata3.00: hard resetting link ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.01: hard resetting link ata3.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.02: hard resetting link ata3.02: softreset failed (timeout) ata3.02: hard resetting link ata3.02: COMRESET failed (errno=-5) ata3.02: reset failed, giving up ata3.15: hard resetting link ata3.15: softreset failed (timeout) ata3.15: hard resetting link ata3.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata3.00: hard resetting link ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.01: hard resetting link ata3.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.02: hard resetting link ata3.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.03: hard resetting link ata3.03: softreset failed (timeout) ata3.03: hard resetting link ata3.03: COMRESET failed (errno=-5) ata3.03: reset failed, giving up ata3.15: hard resetting link ata3.15: softreset failed (timeout) ata3.15: hard resetting link ata3.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata3.00: hard resetting link ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.01: hard resetting link ata3.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.02: hard resetting link ata3.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.03: hard resetting link ata3.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.04: hard resetting link ata3.04: softreset failed (timeout) ata3.04: hard resetting link ata3.04: COMRESET failed (errno=-5) ata3.04: reset failed, giving up ata3.15: hard resetting link ata3.15: softreset failed (timeout) ata3.15: hard resetting link ata3.15: SATA link
Re: pata_acpi resend?
On Tue, 02 Oct 2007 12:40:10 -0400 Jeff Garzik [EMAIL PROTECTED] wrote: As mentioned at the kernel summit... requesting that somebody send me a single patch that adds pata_acpi to the kernel (with all pata_acpi fixes and updates rolled into that patch). Later today... - 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: Integrate ACPI-based PATA/SATA hotplug - version 3
On Tue, Oct 02, 2007 at 11:04:41AM -0400, Jeff Garzik wrote: 1) Check dev-sdev for NULL Ok. 2) remove the unnecessary ata_device loop. If you know the ata_device pointer, you should not throw it away and then do a search to find it again. You need two functions, ata_acpi_ap_notify() and ata_acpi_dev_notify(). Pass 'ap' to the former, and 'dev' to the latter. Both functions should marshal their arguments, then call a common function (presumably what 95% of current ata_acpi_notify does). Sure. 3) Won't this result in a single hotplug event calling ata_ehi_hotplugged() multiple times -- once for the port, and once for each device attached to the port? No - the platform will either send an event for the port or for an individual device. It'll never simultaneously send one for both the port and a device. Semantically the one from the port is a check all children request and the one from the device a check this individual device, but I believe these are both equivalent in the current hotswap implementation. -- Matthew Garrett | [EMAIL PROTECTED] - 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] libata: Integrate ACPI-based PATA/SATA hotplug - version 4
Modern laptops with hotswap bays still tend to utilise a PATA interface
on a SATA bridge, generally with the host controller in some legacy
emulation mode rather than AHCI. This means that the existing hotplug
code in libata is unable to work. The ACPI specification states that
these devices can send notifications when hotswapped, which avoids the
need to obtain notification from the controller. This patch uses the
existing libata-acpi code and simply registers a notification in order
to trigger a rescan whenever the firmware signals an event.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
---
This incorporates Jeff's feedback. sdev is checked for NULL, and
different notifications are registered for ap-level and dev-level
handlers. The core code is split out into a helper function called by
both of these. The other change is the removal of the extraneous newline
from the end of the notification event, to match the upstream change in
the bay driver.
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index c059f78..4d8f1ba 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -14,6 +14,7 @@
#include linux/acpi.h
#include linux/libata.h
#include linux/pci.h
+#include scsi/scsi_device.h
#include libata.h
#include acpi/acpi_bus.h
@@ -66,6 +67,47 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
}
}
+static void ata_acpi_handle_hotplug (struct ata_port *ap, struct kobject *kobj,
+u32 event)
+{
+ char event_string[12];
+ char *envp[] = { event_string, NULL };
+ struct ata_eh_info *ehi = ap-eh_info;
+
+ if (event == 0 || event == 1) {
+ unsigned long flags;
+ spin_lock_irqsave(ap-lock, flags);
+ ata_ehi_clear_desc(ehi);
+ ata_ehi_push_desc(ehi, ACPI event);
+ ata_ehi_hotplugged(ehi);
+ ata_port_freeze(ap);
+ spin_unlock_irqrestore(ap-lock, flags);
+ }
+
+ if (kobj) {
+ sprintf(event_string, BAY_EVENT=%d, event);
+ kobject_uevent_env(kobj, KOBJ_CHANGE, envp);
+ }
+}
+
+static void ata_acpi_dev_notify(acpi_handle handle, u32 event, void *data)
+{
+ struct ata_device *dev = data;
+ struct kobject *kobj = NULL;
+
+ if (dev-sdev)
+ kobj = dev-sdev-sdev_gendev.kobj;
+
+ ata_acpi_handle_hotplug (dev-ap, kobj, event);
+}
+
+static void ata_acpi_ap_notify(acpi_handle handle, u32 event, void *data)
+{
+ struct ata_port *ap = data;
+
+ ata_acpi_handle_hotplug (ap, ap-dev-kobj, event);
+}
+
/**
* ata_acpi_associate - associate ATA host with ACPI objects
* @host: target ATA host
@@ -81,7 +123,7 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
*/
void ata_acpi_associate(struct ata_host *host)
{
- int i;
+ int i, j;
if (!is_pci_dev(host-dev) || libata_noacpi)
return;
@@ -97,6 +139,22 @@ void ata_acpi_associate(struct ata_host *host)
ata_acpi_associate_sata_port(ap);
else
ata_acpi_associate_ide_port(ap);
+
+ if (ap-acpi_handle)
+ acpi_install_notify_handler (ap-acpi_handle,
+ACPI_SYSTEM_NOTIFY,
+ata_acpi_ap_notify,
+ap);
+
+ for (j = 0; j ata_port_max_devices(ap); j++) {
+ struct ata_device *dev = ap-device[j];
+
+ if (dev-acpi_handle)
+ acpi_install_notify_handler (dev-acpi_handle,
+ACPI_SYSTEM_NOTIFY,
+
ata_acpi_dev_notify,
+dev);
+ }
}
}
--
Matthew Garrett | [EMAIL PROTECTED]
-
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]: Sata Sil3512 bug?
Hello Tejun, I build another setup with almost the same hardware. This motherboard had already the latest bios. I notice that the computer does almost never find the hard drive although the controller is found every time (with lspci). So i get no drive (sda) assigned. I don't always see the bios screen from the controller at startup. And in the past it showed the hard drive. So i could not experiment with this motherboard. After that i installed Windows XP and used the orginal (sweex) drivers with the first motherboard. This also makes the data corrupt. So it seems not to be an linux problem. So there is something wrong with the motherboard or the 3512 controller. After that i plugged both hard drives (ide with windows and sata disk) to the Asus board. No data corruption. So the hard disks are'nt the problem either. I'm thinking of replacing both 3512 controllers with a Promise SATA300 TX4. Do you know if there are problems with this device? Friday, September 28, 2007, 6:55:47 PM, you wrote: Alan Cox wrote: sda1 are corrupted (2 to 4 blocks missing). Copying that data back to Windows and it give the same results in Quickpar. So reading does not have problems. The data written to hda1 is correct. We've got a whole pile of reports like this with the 3512 and almost always Nvidia chipset, plus reports of BIOS updates fixing it. That you see something similar on intel boards is a bit worrying. Multiple sil3112/3512 + nvidia chipset problem doesn't usually involve device errors or timeouts. It usually corrupts data silently. And, yeah, data corruption on intel board is really disturbing. MisterE, do you have any processor powersaving mechanism enabled? If so, can you disable all and see whether that changes anything? -- Best regards, MisterEmailto:[EMAIL PROTECTED] - 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 3/3] ide: add CONFIG_IDE_ARCH_OBSOLETE_INIT
Bartlomiej Zolnierkiewicz wrote: Add CONFIG_IDE_ARCH_OBSOLETE_INIT to drivers/ide/Kconfig and use it instead of defining IDE_ARCH_OBSOLETE_INIT in arch/ide.h. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] include/asm-arm26/ide.h |1 - No such file upstream anymore. Looks good otherwise... MBR, 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
Re: [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 4
Jeff Garzik wrote: Matthew Garrett wrote: Modern laptops with hotswap bays still tend to utilise a PATA interface on a SATA bridge, generally with the host controller in some legacy emulation mode rather than AHCI. This means that the existing hotplug code in libata is unable to work. The ACPI specification states that these devices can send notifications when hotswapped, which avoids the need to obtain notification from the controller. This patch uses the existing libata-acpi code and simply registers a notification in order to trigger a rescan whenever the firmware signals an event. Signed-off-by: Matthew Garrett [EMAIL PROTECTED] --- This incorporates Jeff's feedback. sdev is checked for NULL, and different notifications are registered for ap-level and dev-level handlers. The core code is split out into a helper function called by both of these. The other change is the removal of the extraneous newline from the end of the notification event, to match the upstream change in the bay driver. applied Come on, dude! This doesn't even build: UPD include/linux/compile.h drivers/ata/libata-acpi.c: In function ‘ata_acpi_handle_hotplug’: drivers/ata/libata-acpi.c:104: error: ‘struct ata_port’ has no member named ‘eh_info’ drivers/ata/libata-acpi.c: In function ‘ata_acpi_dev_notify’: drivers/ata/libata-acpi.c:130: error: ‘struct ata_device’ has no member named ‘ap’ drivers/ata/libata-acpi.c: In function ‘ata_acpi_associate’: drivers/ata/libata-acpi.c:178: error: implicit declaration of function ‘ata_port_max_devices’ drivers/ata/libata-acpi.c:179: error: ‘struct ata_port’ has no member named ‘device’ make[2]: *** [drivers/ata/libata-acpi.o] Error 1 - 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: Integrate ACPI-based PATA/SATA hotplug - version 4
On Tue, Oct 02, 2007 at 04:38:19PM -0400, Jeff Garzik wrote: Come on, dude! This doesn't even build: Crap, sorry, I've pulled that from the wrong tree. I'll grab you a working one now. -- Matthew Garrett | [EMAIL PROTECTED] - 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 02/10] libata: implement ata_wait_after_reset()
From: Tejun Heo [EMAIL PROTECTED]
On certain device/controller combination, 0xff status is asserted
after reset and doesn't get cleared during 150ms post-reset wait. As
0xff status is interpreted as no device (for good reasons), this can
lead to misdetection on such cases.
This patch implements ata_wait_after_reset() which replaces the 150ms
sleep and waits upto ATA_TMOUT_FF_WAIT if status is 0xff.
ATA_TMOUT_FF_WAIT is currently 800ms which is enough for
HHD424020F7SV00 to get detected but not enough for Quantum GoVault
drive which is known to take upto 2s.
Without parallel probing, spending 2s on 0xff port would incur too
much delay on ata_piix's which use 0xff to indicate empty port and
doesn't have SCR register, so GoVault needs to wait till parallel
probing.
Signed-off-by: Tejun Heo [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/ata/ahci.c | 11 +
drivers/ata/libata-core.c | 67 +++---
drivers/ata/pata_scc.c | 13 +-
drivers/ata/sata_inic162x.c |2 -
include/linux/libata.h |8
5 files changed, 67 insertions(+), 34 deletions(-)
diff -puN drivers/ata/ahci.c~libata-implement-ata_wait_after_reset
drivers/ata/ahci.c
--- a/drivers/ata/ahci.c~libata-implement-ata_wait_after_reset
+++ a/drivers/ata/ahci.c
@@ -1123,15 +1123,8 @@ static int ahci_do_softreset(struct ata_
tf.ctl = ~ATA_SRST;
ahci_exec_polled_cmd(ap, pmp, tf, 0, 0, 0);
- /* spec mandates = 2ms before checking status.
-* We wait 150ms, because that was the magic delay used for
-* ATAPI devices in Hale Landis's ATADRVR, for the period of time
-* between when the ATA command register is written, and then
-* status is checked. Because waiting for a while before
-* checking status is fine, post SRST, we perform this magic
-* delay here as well.
-*/
- msleep(150);
+ /* wait a while before checking status */
+ ata_wait_after_reset(ap, deadline);
rc = ata_wait_ready(ap, deadline);
/* link occupied, -ENODEV too is an error */
diff -puN drivers/ata/libata-core.c~libata-implement-ata_wait_after_reset
drivers/ata/libata-core.c
--- a/drivers/ata/libata-core.c~libata-implement-ata_wait_after_reset
+++ a/drivers/ata/libata-core.c
@@ -3104,6 +3104,55 @@ int ata_busy_sleep(struct ata_port *ap,
}
/**
+ * ata_wait_after_reset - wait before checking status after reset
+ * @ap: port containing status register to be polled
+ * @deadline: deadline jiffies for the operation
+ *
+ * After reset, we need to pause a while before reading status.
+ * Also, certain combination of controller and device report 0xff
+ * for some duration (e.g. until SATA PHY is up and running)
+ * which is interpreted as empty port in ATA world. This
+ * function also waits for such devices to get out of 0xff
+ * status.
+ *
+ * LOCKING:
+ * Kernel thread context (may sleep).
+ */
+void ata_wait_after_reset(struct ata_port *ap, unsigned long deadline)
+{
+ unsigned long until = jiffies + ATA_TMOUT_FF_WAIT;
+
+ if (time_before(until, deadline))
+ deadline = until;
+
+ /* Spec mandates = 2ms before checking status. We wait
+* 150ms, because that was the magic delay used for ATAPI
+* devices in Hale Landis's ATADRVR, for the period of time
+* between when the ATA command register is written, and then
+* status is checked. Because waiting for a while before
+* checking status is fine, post SRST, we perform this magic
+* delay here as well.
+*
+* Old drivers/ide uses the 2mS rule and then waits for ready.
+*/
+ msleep(150);
+
+ /* Wait for 0xff to clear. Some SATA devices take a long time
+* to clear 0xff after reset. For example, HHD424020F7SV00
+* iVDR needs = 800ms while. Quantum GoVault needs even more
+* than that.
+*/
+ while (1) {
+ u8 status = ata_chk_status(ap);
+
+ if (status != 0xff || time_after(jiffies, deadline))
+ return;
+
+ msleep(50);
+ }
+}
+
+/**
* ata_wait_ready - sleep until BSY clears, or timeout
* @ap: port containing status register to be polled
* @deadline: deadline jiffies for the operation
@@ -3219,17 +3268,8 @@ static int ata_bus_softreset(struct ata_
udelay(20); /* FIXME: flush */
iowrite8(ap-ctl, ioaddr-ctl_addr);
- /* spec mandates = 2ms before checking status.
-* We wait 150ms, because that was the magic delay used for
-* ATAPI devices in Hale Landis's ATADRVR, for the period of time
-* between when the ATA command register is written, and then
-* status is checked. Because waiting for a while before
-* checking status is fine, post SRST, we perform this magic
-* delay here
[patch 04/10] Ata: pata_marvell, use ioread* for iomap-ped memory
From: Jiri Slaby [EMAIL PROTECTED] pata_marvell, use ioread* for iomap-ped memory read* on pci_iomapped memory is incorrect, fix it Signed-off-by: Jiri Slaby [EMAIL PROTECTED] Acked-by: Alan Cox [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/ata/pata_marvell.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN drivers/ata/pata_marvell.c~ata-pata_marvell-use-ioread-for-iomap-ped-memory drivers/ata/pata_marvell.c --- a/drivers/ata/pata_marvell.c~ata-pata_marvell-use-ioread-for-iomap-ped-memory +++ a/drivers/ata/pata_marvell.c @@ -45,10 +45,10 @@ static int marvell_pre_reset(struct ata_ return -ENOMEM; printk(BAR5:); for(i = 0; i = 0x0F; i++) - printk(%02X:%02X , i, readb(barp + i)); + printk(%02X:%02X , i, ioread8(barp + i)); printk(\n); - devices = readl(barp + 0x0C); + devices = ioread32(barp + 0x0C); pci_iounmap(pdev, barp); if ((pdev-device == 0x6145) (ap-port_no == 0) _ - 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 07/10] libata: expose AN to user space
From: Kristen Carlson Accardi [EMAIL PROTECTED]
If Asynchronous Notification of media change events is supported, pass that
information up to the SCSI layer.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/ata/libata-scsi.c |3 +++
1 file changed, 3 insertions(+)
diff -puN drivers/ata/libata-scsi.c~libata-expose-an-to-user-space
drivers/ata/libata-scsi.c
--- a/drivers/ata/libata-scsi.c~libata-expose-an-to-user-space
+++ a/drivers/ata/libata-scsi.c
@@ -773,6 +773,9 @@ static void ata_scsi_dev_config(struct s
blk_queue_max_hw_segments(q, q-max_hw_segments - 1);
}
+ if (dev-flags ATA_DFLAG_AN)
+ sdev-media_change_notify = 1;
+
if (dev-flags ATA_DFLAG_NCQ) {
int depth;
_
-
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 06/10] scsi: expose AN support to user space
From: Kristen Carlson Accardi [EMAIL PROTECTED]
If a scsi_device supports async notification for media change, then let user
space know this capability exists by creating a new sysfs entry
media_change_notify, which will be 1 if it is supported, and 0 if not
supported. Create a routine which allows scsi devices to send a uevent when
media change events occur.
Signed-off-by: Kristen Carlson Accardi [EMAIL PROTECTED]
Cc: Jeff Garzik [EMAIL PROTECTED]
Cc: Tejun Heo [EMAIL PROTECTED]
Cc: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/scsi/scsi_lib.c| 83 +++
drivers/scsi/scsi_scan.c |1
drivers/scsi/scsi_sysfs.c | 13 +
include/scsi/scsi_device.h | 15 +-
4 files changed, 111 insertions(+), 1 deletion(-)
diff -puN drivers/scsi/scsi_lib.c~scsi-expose-an-support-to-user-space
drivers/scsi/scsi_lib.c
--- a/drivers/scsi/scsi_lib.c~scsi-expose-an-support-to-user-space
+++ a/drivers/scsi/scsi_lib.c
@@ -64,6 +64,11 @@ static struct scsi_host_sg_pool scsi_sg_
};
#undef SP
+/* must match scsi_device_event enum in scsi_device.h */
+static char * scsi_device_event_strings[] = {
+ MEDIA_CHANGE=1,
+};
+
static void scsi_run_queue(struct request_queue *q);
/*
@@ -2007,6 +2012,84 @@ scsi_device_set_state(struct scsi_device
EXPORT_SYMBOL(scsi_device_set_state);
/**
+ * scsi_device_set_event - Add a new Async event to the event list
+ * @sdev: scsi_device event occurred on
+ * @event: the scsi device event
+ *
+ * Add a new scsi_device_event_info struct to the scsi_device_event_list
+ * queue. This may be called from interrupt context.
+ *
+ * Returns 0 if successful, -ENOMEM otherwise.
+ */
+static int
+scsi_device_set_event(struct scsi_device *sdev, enum scsi_device_event event)
+{
+ struct scsi_device_event_info *scsi_event;
+ unsigned long flags;
+
+ scsi_event = kzalloc(sizeof(*scsi_event), GFP_ATOMIC);
+ if (!scsi_event)
+ return -ENOMEM;
+ INIT_LIST_HEAD(scsi_event-link);
+ scsi_event-event = event;
+ spin_lock_irqsave(sdev-list_lock, flags);
+ list_add_tail(scsi_event-link, sdev-sdev_event_list);
+ spin_unlock_irqrestore(sdev-list_lock, flags);
+ return 0;
+}
+
+/**
+ * scsi_device_event_notify_thread - send a uevent for each scsi event
+ * @work: work struct for scsi_device
+ *
+ * Traverse the queue of scsi device events, dequeue each event and
+ * send a uevent. Frees event. May not be called from interrupt.
+ */
+static void scsi_event_notify_thread(struct work_struct *work)
+{
+ struct scsi_device *sdev;
+ char *envp[] = { NULL, NULL };
+ struct list_head *tmp;
+ struct list_head *next;
+ struct scsi_device_event_info *sdev_event;
+ unsigned long flags;
+
+ sdev = container_of(work, struct scsi_device, ew.work);
+ list_for_each_safe(tmp, next, sdev-sdev_event_list) {
+ sdev_event = list_entry(tmp, struct scsi_device_event_info,
+ link);
+ spin_lock_irqsave(sdev-list_lock, flags);
+ list_del(sdev_event-link);
+ spin_unlock_irqrestore(sdev-list_lock, flags);
+ envp[0] = scsi_device_event_strings[sdev_event-event-1];
+ kobject_uevent_env(sdev-sdev_gendev.kobj, KOBJ_CHANGE, envp);
+ kfree(sdev_event);
+ }
+}
+
+/**
+ * scsi_device_event_notify - store event info and send an event
+ * @sdev: scsi_device event occurred on
+ * @event: the scsi device event
+ *
+ * Store the event information and then switch process context
+ * so that the event may be sent to user space.
+ * This may be called from interrupt context.
+ *
+ * Returns 0 if successful, -ENOMEM otherwise.
+ */
+int scsi_device_event_notify(struct scsi_device *sdev, enum scsi_device_event
event)
+{
+ int rc;
+
+ rc = scsi_device_set_event(sdev, event);
+ if (!rc)
+ execute_in_process_context(scsi_event_notify_thread, sdev-ew);
+ return rc;
+}
+EXPORT_SYMBOL_GPL(scsi_device_event_notify);
+
+/**
* scsi_device_quiesce - Block user issued commands.
* @sdev: scsi device to quiesce.
*
diff -puN drivers/scsi/scsi_scan.c~scsi-expose-an-support-to-user-space
drivers/scsi/scsi_scan.c
--- a/drivers/scsi/scsi_scan.c~scsi-expose-an-support-to-user-space
+++ a/drivers/scsi/scsi_scan.c
@@ -253,6 +253,7 @@ static struct scsi_device *scsi_alloc_sd
INIT_LIST_HEAD(sdev-same_target_siblings);
INIT_LIST_HEAD(sdev-cmd_list);
INIT_LIST_HEAD(sdev-starved_entry);
+ INIT_LIST_HEAD(sdev-sdev_event_list);
spin_lock_init(sdev-list_lock);
sdev-sdev_gendev.parent = get_device(starget-dev);
diff -puN drivers/scsi/scsi_sysfs.c~scsi-expose-an-support-to-user-space
drivers/scsi/scsi_sysfs.c
---
[patch 05/10] drivers/ata/pata_ixp4xx_cf.c: ioremap return code check
From: Scott Thompson [EMAIL PROTECTED] Add missing ioremap return checks. Signed-off-by: Scott Thompson postfail at hushmail.com Acked-by: Tejun Heo [EMAIL PROTECTED] Cc: Alan Cox [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] --- drivers/ata/pata_ixp4xx_cf.c |3 +++ 1 file changed, 3 insertions(+) diff -puN drivers/ata/pata_ixp4xx_cf.c~drivers-ata-pata_ixp4xx_cfc-ioremap-return-code-check drivers/ata/pata_ixp4xx_cf.c --- a/drivers/ata/pata_ixp4xx_cf.c~drivers-ata-pata_ixp4xx_cfc-ioremap-return-code-check +++ a/drivers/ata/pata_ixp4xx_cf.c @@ -195,6 +195,9 @@ static __devinit int ixp4xx_pata_probe(s data-cs0 = devm_ioremap(pdev-dev, cs0-start, 0x1000); data-cs1 = devm_ioremap(pdev-dev, cs1-start, 0x1000); + if (!data-cs0 || !data-cs1) + return -ENOMEM; + irq = platform_get_irq(pdev, 0); if (irq) set_irq_type(irq, IRQT_RISING); _ - 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 10/10] libata: fix (hopefully) all the remaining problems with devices failing setup/identify
From: Alan [EMAIL PROTECTED]
Two fixes in this test patch. One of them allows old CF cards to refuse
pio mode setting, and one to wait for the drive to settle after a set
features changes the speed settings, which is based upon the workarounds
used by drivers/ide.
Please test and report back if you have an afflicted system. This patch
isn't for merging just testing.
The CF card fix will still display errors when the card works (got fixes
for that once I know the cure works) but should then be found/usable.
Not signed off by anyone, not for merging
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/ata/libata-core.c | 15 +++
1 file changed, 15 insertions(+)
diff -puN
drivers/ata/libata-core.c~libata-fix-hopefully-all-the-remaining-problems-with
drivers/ata/libata-core.c
---
a/drivers/ata/libata-core.c~libata-fix-hopefully-all-the-remaining-problems-with
+++ a/drivers/ata/libata-core.c
@@ -5933,6 +5933,7 @@ inline unsigned int ata_host_intr (struc
{
struct ata_eh_info *ehi = ap-link.eh_info;
u8 status, host_stat = 0;
+ int i;
VPRINTK(ata%u: protocol %d task_state %d\n,
ap-print_id, qc-tf.protocol, ap-hsm_task_state);
@@ -5989,6 +5990,20 @@ inline unsigned int ata_host_intr (struc
if (unlikely(status ATA_BUSY))
goto idle_irq;
+ if (unlikely(qc-tf.command == ATA_CMD_SET_FEATURES
+ qc-tf.feature == SETFEATURES_XFER)) {
+ /* Let the timings change settle and the drive catch up as
+ some hardware needs up to 10uS to get its brain back in
+ gear. Taken from the workarounds in drivers/ide done by
+ Matthew Faupel/Niccolo Rigacci */
+ for (i = 0; i 10; i++) {
+ if ((status (ATA_BUSY | ATA_DRQ | ATA_ERR)) == 0)
+ break;
+ udelay(1);
+ status = ata_chk_status(ap);
+ }
+ }
+
/* ack bmdma irq events */
ap-ops-irq_clear(ap);
_
-
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 09/10] libata_scsi: Fix transfer lengths
From: Alan Cox [EMAIL PROTECTED]
This should get into the base tree very soon anyway but it fixes a ton of
devices so it would be nice to have in -mm so I can get people to test -mm not
-mm + a bit when reporting ATAPI problems.
Signed-off-by: Alan Cox [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
drivers/ata/libata-scsi.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff -puN drivers/ata/libata-scsi.c~libata_scsi-fix-transfer-lengths
drivers/ata/libata-scsi.c
--- a/drivers/ata/libata-scsi.c~libata_scsi-fix-transfer-lengths
+++ a/drivers/ata/libata-scsi.c
@@ -2336,8 +2336,8 @@ static void atapi_request_sense(struct a
qc-tf.feature |= ATAPI_PKT_DMA;
} else {
qc-tf.protocol = ATA_PROT_ATAPI;
- qc-tf.lbam = (8 * 1024) 0xff;
- qc-tf.lbah = (8 * 1024) 8;
+ qc-tf.lbam = SCSI_SENSE_BUFFERSIZE;
+ qc-tf.lbah = 0;
}
qc-nbytes = SCSI_SENSE_BUFFERSIZE;
@@ -2446,6 +2446,7 @@ static unsigned int atapi_xlat(struct at
struct ata_device *dev = qc-dev;
int using_pio = (dev-flags ATA_DFLAG_PIO);
int nodata = (scmd-sc_data_direction == DMA_NONE);
+ unsigned int nbytes;
memset(qc-cdb, 0, dev-cdb_len);
memcpy(qc-cdb, scmd-cmnd, scmd-cmd_len);
@@ -2465,14 +2466,20 @@ static unsigned int atapi_xlat(struct at
if (!using_pio ata_check_atapi_dma(qc))
using_pio = 1;
+ /* Some controller variants snoop this value for Packet transfers
+ to do state machine and FIFO management. Thus we want to set it
+ properly, and for DMA where it is effectively meaningless */
+ nbytes = min(qc-nbytes, (unsigned int)63 * 1024);
+
+ qc-tf.lbam = (nbytes 0xFF);
+ qc-tf.lbah = (nbytes 8);
+
if (using_pio || nodata) {
/* no data, or PIO data xfer */
if (nodata)
qc-tf.protocol = ATA_PROT_ATAPI_NODATA;
else
qc-tf.protocol = ATA_PROT_ATAPI;
- qc-tf.lbam = (8 * 1024) 0xff;
- qc-tf.lbah = (8 * 1024) 8;
} else {
/* DMA data xfer */
qc-tf.protocol = ATA_PROT_ATAPI_DMA;
@@ -2483,6 +2490,9 @@ static unsigned int atapi_xlat(struct at
qc-tf.feature |= ATAPI_DMADIR;
}
+
+ /* FIXME: We need to translate 0x05 READ_BLOCK_LIMITS to a MODE_SENSE
+ as ATAPI tape drives don't get this right otherwise */
return 0;
}
_
-
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 3/3] ide: add CONFIG_IDE_ARCH_OBSOLETE_INIT
On Tuesday 02 October 2007, Sergei Shtylyov wrote: Bartlomiej Zolnierkiewicz wrote: Add CONFIG_IDE_ARCH_OBSOLETE_INIT to drivers/ide/Kconfig and use it instead of defining IDE_ARCH_OBSOLETE_INIT in arch/ide.h. Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] include/asm-arm26/ide.h |1 - No such file upstream anymore. Looks good otherwise... Thanks, patch updated. Bart - 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 9/15] cs5530: remove needless ide_lock taking
On Tuesday 02 October 2007, Alan Cox wrote: - spin_lock_irqsave(ide_lock, flags); - /* all CPUs (there should only be one CPU with this chipset) */ - NAK What about pre-emptible kernels. Put in a private lock. All the removed code resided in init_chipset_cs5530() which is called only during the controller initialization. Moreover pata_cs5530 also don't have any locking in cs5530_init_chip(). Bart - 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 12/15] ide: remove -dma_master field from ide_hwif_t
On Tuesday 02 October 2007, Jeff Garzik wrote:
Bartlomiej Zolnierkiewicz wrote:
On Monday 01 October 2007, Jeff Garzik wrote:
Bartlomiej Zolnierkiewicz wrote:
* Convert cmd64x, hpt366 and pdc202xx_old host drivers to use
pci_resource_start(hwif-pci_dev, 4) instead of hwif-dma_master.
Before using pci_resource_start(), the code should check
pci_resource_len() to ensure it is the appropriate size.
It would be very wise to ensure that pci_resource_flags()IORESOURCE_IO
is true, too.
Sure but since the old code hasn't been doing these checks (old code
just did pci_resource_start() - hwif-dma_base - hwif-dma_master)
this is a separate issue from what the patch tries to achieve.
Nonetheless this is duplicating an existing bug $N times... not ideal :)
The existing bug is that the methods converted to use pci_resource_start()
may be set in hwif instance and used even if the BAR4 is invalid. Therefore
the above patch is correct and it isn't duplicating the existing bug. :)
However I agree that all these pci_resource_start()s could be a bit confusing
so here is 'take 2'.
[PATCH] ide: remove -dma_master field from ide_hwif_t (take 2)
* Convert cmd64x, hpt366 and pdc202xx_old host drivers to use
pci_resource_start(hwif-pci_dev, 4) instead of hwif-dma_master.
* Remove no longer needed -dma_master field from ide_hwif_t.
v2:
* Use the more readable 'hwif-dma_base - (hwif-channel * 8)' instead of
pci_resource_start(hwif-pci_dev, 4).
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-dma.c |7 ---
drivers/ide/ide.c |2 --
drivers/ide/pci/cmd64x.c |8 +---
drivers/ide/pci/hpt366.c | 21 +++--
drivers/ide/pci/pdc202xx_old.c | 12 ++--
include/linux/ide.h|1 -
6 files changed, 22 insertions(+), 29 deletions(-)
Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -1006,11 +1006,6 @@ void ide_setup_dma(ide_hwif_t *hwif, uns
hwif-dma_base = base;
- if (hwif-mate)
- hwif-dma_master = hwif-channel ? hwif-mate-dma_base : base;
- else
- hwif-dma_master = base;
-
if (!(hwif-dma_command))
hwif-dma_command = hwif-dma_base;
if (!(hwif-dma_vendor1))
@@ -1052,8 +1047,6 @@ void ide_setup_dma(ide_hwif_t *hwif, uns
hwif-drives[1].name, (dma_stat 0x40) ? DMA : pio);
}
printk(\n);
-
- BUG_ON(!hwif-dma_master);
}
EXPORT_SYMBOL_GPL(ide_setup_dma);
Index: b/drivers/ide/ide.c
===
--- a/drivers/ide/ide.c
+++ b/drivers/ide/ide.c
@@ -470,7 +470,6 @@ static void ide_hwif_restore(ide_hwif_t
#endif
hwif-dma_base = tmp_hwif-dma_base;
- hwif-dma_master= tmp_hwif-dma_master;
hwif-dma_command = tmp_hwif-dma_command;
hwif-dma_vendor1 = tmp_hwif-dma_vendor1;
hwif-dma_status= tmp_hwif-dma_status;
@@ -604,7 +603,6 @@ void ide_unregister(unsigned int index)
(void) ide_release_dma(hwif);
hwif-dma_base = 0;
- hwif-dma_master = 0;
hwif-dma_command = 0;
hwif-dma_vendor1 = 0;
hwif-dma_status = 0;
Index: b/drivers/ide/pci/cmd64x.c
===
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -333,13 +333,14 @@ static void cmd64x_set_dma_mode(ide_driv
static int cmd648_ide_dma_end (ide_drive_t *drive)
{
ide_hwif_t *hwif= HWIF(drive);
+ unsigned long addr = hwif-dma_base - (hwif-channel * 8) + 0x01;
int err = __ide_dma_end(drive);
u8 irq_mask= hwif-channel ? MRDMODE_INTR_CH1 :
MRDMODE_INTR_CH0;
- u8 mrdmode = inb(hwif-dma_master + 0x01);
+ u8 mrdmode = inb(addr);
/* clear the interrupt bit */
- outb(mrdmode | irq_mask, hwif-dma_master + 0x01);
+ outb(mrdmode | irq_mask, addr);
return err;
}
@@ -364,10 +365,11 @@ static int cmd64x_ide_dma_end (ide_drive
static int cmd648_ide_dma_test_irq (ide_drive_t *drive)
{
ide_hwif_t *hwif= HWIF(drive);
+ unsigned long addr = hwif-dma_base - (hwif-channel * 8) + 0x01;
u8 irq_mask = hwif-channel ? MRDMODE_INTR_CH1 :
MRDMODE_INTR_CH0;
u8 dma_stat = inb(hwif-dma_status);
- u8 mrdmode = inb(hwif-dma_master + 0x01);
+ u8 mrdmode = inb(addr);
#ifdef DEBUG
printk(%s: dma_stat: 0x%02x mrdmode: 0x%02x irq_mask: 0x%02x\n,
Index:
Re: [PATCH] libata: Integrate ACPI-based PATA/SATA hotplug - version 4
Fix libata-acpi.c build failure.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
---
Sorry, I'd diffed the original against libata-dev master rather than
ALL. This tidies up the changes.
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 6896831..5ebbf16 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -101,7 +101,7 @@ static void ata_acpi_handle_hotplug (struct ata_port *ap,
struct kobject *kobj,
{
char event_string[12];
char *envp[] = { event_string, NULL };
- struct ata_eh_info *ehi = ap-eh_info;
+ struct ata_eh_info *ehi = ap-link.eh_info;
if (event == 0 || event == 1) {
unsigned long flags;
@@ -127,7 +127,7 @@ static void ata_acpi_dev_notify(acpi_handle handle, u32
event, void *data)
if (dev-sdev)
kobj = dev-sdev-sdev_gendev.kobj;
- ata_acpi_handle_hotplug (dev-ap, kobj, event);
+ ata_acpi_handle_hotplug (dev-link-ap, kobj, event);
}
static void ata_acpi_ap_notify(acpi_handle handle, u32 event, void *data)
@@ -175,8 +175,8 @@ void ata_acpi_associate(struct ata_host *host)
ata_acpi_ap_notify,
ap);
- for (j = 0; j ata_port_max_devices(ap); j++) {
- struct ata_device *dev = ap-device[j];
+ for (j = 0; j ata_link_max_devices(ap-link); j++) {
+ struct ata_device *dev = ap-link.device[j];
if (dev-acpi_handle)
acpi_install_notify_handler (dev-acpi_handle,
--
Matthew Garrett | [EMAIL PROTECTED]
-
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 3/15] qd65xx: fix deadlock on error handling
Bartlomiej Zolnierkiewicz wrote:
ACK everything else (that I snipped)...
@@ -303,6 +281,7 @@ static void qd6580_set_pio_mode(ide_driv
static int __init qd_testreg(int port)
{
+ static DEFINE_SPINLOCK(qd65xx_lock);
unsigned long flags;
u8 savereg, readreg;
At this point, the lock is largely pointless, isn't it?
Seems like you might as well use local_irq_save/restore.
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: [regression] 2.6.23 sata_mv EH updates broke my 7042 controller
Olof Johansson wrote: On Mon, Oct 01, 2007 at 06:37:44PM -0400, Jeff Garzik wrote: Olof Johansson wrote: Hardware config in my case: Highpoint 2310 controller PPC (big endian) WD Raptor disk Works fine with the other controller I've been using (SIL24), and works fine if I revert the driver. It also works fine if I disable the IOMMU. This would point towards either a stale dma mapping, or a missing setup of one. Not being much at home in the SATA drivers I could keep digging but I figured I'd bring it up first in case it rings a bell for someone. The IOMMU data point is certainly interesting. Nothing jumps out on a re-review of the patch, so keep digging and let us know ;-) Looks like it's caused by enabling vmerge (which tends to be on for the common PPC defconfigs). If I disable it, things look OK. Perhaps the Marvell controller doesn't like requests larger than 64K, or wrapping some boundary. Do you have access to erratas/docs? I have verified it on a powermac now as well (had a quick scare that it might have been some problem with the PA Semi IOMMU, but no). FWIW: I just tried the 6042 on my AMD64 platform with iommu=force, and was unable to reproduce any trouble. You could try changing MV_DMA_BOUNDARY to 0xU and see what happens. I'll also look through my errata, to see what is different between 6042 and 7042, if anything. 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 9/15] cs5530: remove needless ide_lock taking
All the removed code resided in init_chipset_cs5530() which is called only during the controller initialization. Moreover pata_cs5530 also don't have any locking in cs5530_init_chip(). Fair enough, and I haven't found a reason for the locking being needed from doc reviews (hence its not in libata). - 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] libata: Integrate ACPI-based PATA/SATA hotplug - version 5
Modern laptops with hotswap bays still tend to utilise a PATA interface
on a SATA bridge, generally with the host controller in some legacy
emulation mode rather than AHCI. This means that the existing hotplug
code in libata is unable to work. The ACPI specification states that
these devices can send notifications when hotswapped, which avoids the
need to obtain notification from the controller. This patch uses the
existing libata-acpi code and simply registers a notification in order
to trigger a rescan whenever the firmware signals an event.
Signed-off-by: Matthew Garrett [EMAIL PROTECTED]
---
Diffed against #upstream. Fairly sure I've got it right this time...
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index a276c06..5ebbf16 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -14,6 +14,7 @@
#include linux/acpi.h
#include linux/libata.h
#include linux/pci.h
+#include scsi/scsi_device.h
#include libata.h
#include acpi/acpi_bus.h
@@ -95,6 +96,47 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
}
}
+static void ata_acpi_handle_hotplug (struct ata_port *ap, struct kobject *kobj,
+u32 event)
+{
+ char event_string[12];
+ char *envp[] = { event_string, NULL };
+ struct ata_eh_info *ehi = ap-link.eh_info;
+
+ if (event == 0 || event == 1) {
+ unsigned long flags;
+ spin_lock_irqsave(ap-lock, flags);
+ ata_ehi_clear_desc(ehi);
+ ata_ehi_push_desc(ehi, ACPI event);
+ ata_ehi_hotplugged(ehi);
+ ata_port_freeze(ap);
+ spin_unlock_irqrestore(ap-lock, flags);
+ }
+
+ if (kobj) {
+ sprintf(event_string, BAY_EVENT=%d, event);
+ kobject_uevent_env(kobj, KOBJ_CHANGE, envp);
+ }
+}
+
+static void ata_acpi_dev_notify(acpi_handle handle, u32 event, void *data)
+{
+ struct ata_device *dev = data;
+ struct kobject *kobj = NULL;
+
+ if (dev-sdev)
+ kobj = dev-sdev-sdev_gendev.kobj;
+
+ ata_acpi_handle_hotplug (dev-link-ap, kobj, event);
+}
+
+static void ata_acpi_ap_notify(acpi_handle handle, u32 event, void *data)
+{
+ struct ata_port *ap = data;
+
+ ata_acpi_handle_hotplug (ap, ap-dev-kobj, event);
+}
+
/**
* ata_acpi_associate - associate ATA host with ACPI objects
* @host: target ATA host
@@ -110,7 +152,7 @@ static void ata_acpi_associate_ide_port(struct ata_port *ap)
*/
void ata_acpi_associate(struct ata_host *host)
{
- int i;
+ int i, j;
if (!is_pci_dev(host-dev) || libata_noacpi)
return;
@@ -126,6 +168,22 @@ void ata_acpi_associate(struct ata_host *host)
ata_acpi_associate_sata_port(ap);
else
ata_acpi_associate_ide_port(ap);
+
+ if (ap-acpi_handle)
+ acpi_install_notify_handler (ap-acpi_handle,
+ACPI_SYSTEM_NOTIFY,
+ata_acpi_ap_notify,
+ap);
+
+ for (j = 0; j ata_link_max_devices(ap-link); j++) {
+ struct ata_device *dev = ap-link.device[j];
+
+ if (dev-acpi_handle)
+ acpi_install_notify_handler (dev-acpi_handle,
+ACPI_SYSTEM_NOTIFY,
+
ata_acpi_dev_notify,
+dev);
+ }
}
}
--
Matthew Garrett | [EMAIL PROTECTED]
-
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] libata: fix for sata_mv 64KB DMA segments
Fix bug in sata_mv for cases where the IOMMU layer has merged SG entries
to larger than 64KB. They need to be split up before being sent to
the driver.
Just for simplicity's sake, split up at 64K boundary instead of 64K size,
since that's what the common code does anyway.
Signed-off-by: Olof Johansson [EMAIL PROTECTED]
---
On Tue, Oct 02, 2007 at 07:23:10PM -0400, Jeff Garzik wrote:
Olof Johansson wrote:
On Mon, Oct 01, 2007 at 06:37:44PM -0400, Jeff Garzik wrote:
Looks like it's caused by enabling vmerge (which tends to be on for the
common PPC defconfigs). If I disable it, things look OK.
Perhaps the Marvell controller doesn't like requests larger than 64K,
or wrapping some boundary. Do you have access to erratas/docs?
I have verified it on a powermac now as well (had a quick scare that it
might have been some problem with the PA Semi IOMMU, but no).
FWIW: I just tried the 6042 on my AMD64 platform with iommu=force, and was
unable to reproduce any trouble.
You could try changing MV_DMA_BOUNDARY to 0xU and see what happens.
As per discussion on IRC, it was really caused by mv_fill_sg() not
handing SG entries larger than 64K properly. Below patch fixes it to
behave like ata_fill_sg() instead.
Works OK here after some light testing (restoring my corrupted root
filesystem and running a few fscks on it, among other things).
Thanks,
Olof
diff --git a/drivers/ata/sata_mv.c b/drivers/ata/sata_mv.c
index 11bf6c7..1a82e22 100644
--- a/drivers/ata/sata_mv.c
+++ b/drivers/ata/sata_mv.c
@@ -1139,15 +1139,27 @@ static unsigned int mv_fill_sg(struct ata_queued_cmd
*qc)
dma_addr_t addr = sg_dma_address(sg);
u32 sg_len = sg_dma_len(sg);
- mv_sg-addr = cpu_to_le32(addr 0x);
- mv_sg-addr_hi = cpu_to_le32((addr 16) 16);
- mv_sg-flags_size = cpu_to_le32(sg_len 0x);
+ while (sg_len) {
+ u32 offset = addr 0x;
+ u32 len = sg_len;
- if (ata_sg_is_last(sg, qc))
- mv_sg-flags_size |= cpu_to_le32(EPRD_FLAG_END_OF_TBL);
+ if ((offset + sg_len 0x1))
+ len = 0x1 - offset;
+
+ mv_sg-addr = cpu_to_le32(addr 0x);
+ mv_sg-addr_hi = cpu_to_le32((addr 16) 16);
+ mv_sg-flags_size = cpu_to_le32(len);
+
+ sg_len -= len;
+ addr += len;
+
+ if (!sg_len ata_sg_is_last(sg, qc))
+ mv_sg-flags_size |=
cpu_to_le32(EPRD_FLAG_END_OF_TBL);
+
+ mv_sg++;
+ n_sg++;
+ }
- mv_sg++;
- n_sg++;
}
return n_sg;
-
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: sil24 PMP works with ST3500641AS but not HDS721010KLA330
On Tue, Oct 02, 2007 at 10:04:45AM -0700, Marc MERLIN wrote: Howdy, I've had a system with 2.6.22.1 for a while, running 10 drives behind a PMP on a sil24 card with no problems. Recently, I swapped 5 250GB drives with 5 TB drives. The 5 TB drives eventually get detected, but do not work reliably. Details are below. This is all on 2.6.22.1-libata-tj-20070803. I noticed that 20070808 is out, but it says it fixed NCQ over PMP, and NCQ was working fine with my 500GB drives, so I'm not sure it's that. I tried with 20070808. Boot was better, so it seems to have helped. I guess the NCQ fix was relevant for my TB drives but not needed for the 500GB ones. I still got this when the array was built, but it didn't seem to prevent it from being built and from working: ata3.04: exception Emask 0x0 SAct 0xff SErr 0x0 action 0x2 frozen ata3.04: cmd 61/c0:00:7f:94:04/00:00:71:00:00/40 tag 0 cdb 0x0 data 98304 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3.04: cmd 61/00:08:3f:95:04/01:00:71:00:00/40 tag 1 cdb 0x0 data 131072 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3.04: cmd 61/08:10:77:94:04/00:00:71:00:00/40 tag 2 cdb 0x0 data 4096 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3.04: cmd 61/90:18:3f:96:04/00:00:71:00:00/40 tag 3 cdb 0x0 data 73728 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3.04: cmd 61/20:20:57:93:04/01:00:71:00:00/40 tag 4 cdb 0x0 data 147456 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3.04: cmd 61/70:28:cf:96:04/00:00:71:00:00/40 tag 5 cdb 0x0 data 57344 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3.04: cmd 61/00:30:3f:97:04/01:00:71:00:00/40 tag 6 cdb 0x0 data 131072 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3.04: cmd 61/20:38:3f:98:04/01:00:71:00:00/40 tag 7 cdb 0x0 data 147456 out res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) ata3.15: hard resetting link ata3.15: SATA link up 3.0 Gbps (SStatus 123 SControl 0) ata3.00: hard resetting link ata3.00: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.01: hard resetting link ata3.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.02: hard resetting link ata3.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.03: hard resetting link ata3.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.04: hard resetting link ata3.04: SATA link up 3.0 Gbps (SStatus 123 SControl 300) ata3.05: hard resetting link ata3.05: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata3.00: configured for UDMA/100 ata3.01: configured for UDMA/100 ata3.02: configured for UDMA/100 ata3.03: configured for UDMA/100 ata3.04: configured for UDMA/100 ata3: EH complete sd 3:0:0:0: [sdc] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:0:0:0: [sdc] Write Protect is off sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:1:0:0: [sdd] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:1:0:0: [sdd] Write Protect is off sd 3:1:0:0: [sdd] Mode Sense: 00 3a 00 00 sd 3:1:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:2:0:0: [sde] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:2:0:0: [sde] Write Protect is off sd 3:2:0:0: [sde] Mode Sense: 00 3a 00 00 sd 3:2:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:3:0:0: [sdf] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:3:0:0: [sdf] Write Protect is off sd 3:3:0:0: [sdf] Mode Sense: 00 3a 00 00 sd 3:3:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:4:0:0: [sdg] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:4:0:0: [sdg] Write Protect is off sd 3:4:0:0: [sdg] Mode Sense: 00 3a 00 00 sd 3:4:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:0:0:0: [sdc] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:0:0:0: [sdc] Write Protect is off sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00 sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:1:0:0: [sdd] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:1:0:0: [sdd] Write Protect is off sd 3:1:0:0: [sdd] Mode Sense: 00 3a 00 00 sd 3:1:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:2:0:0: [sde] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:2:0:0: [sde] Write Protect is off sd 3:2:0:0: [sde] Mode Sense: 00 3a 00 00 sd 3:2:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:3:0:0: [sdf] 1953525168 512-byte hardware sectors (1000205 MB) sd 3:3:0:0: [sdf] Write Protect is off sd 3:3:0:0: [sdf] Mode Sense: 00 3a 00 00 sd 3:3:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 3:4:0:0: [sdg] 1953525168
Re: sil24 PMP works with ST3500641AS but not HDS721010KLA330
Marc MERLIN wrote: Howdy, I've had a system with 2.6.22.1 for a while, running 10 drives behind a PMP on a sil24 card with no problems. Recently, I swapped 5 250GB drives with 5 TB drives. The 5 TB drives eventually get detected, but do not work reliably. 1. Does booting with fewer number of drives (say 5) help? 2. Does limiting PHY speed to 1.5Gbps using DIP switch on the harddrive help? -- 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 2/2] libata: change the last state of pio read to HSM_ST_IDLE
Jeff Garzik wrote: Albert Lee wrote: Patch 2/2: After reading the last pio data block, the HSM is waiting for device to be idle, not waiting for the last interrupt. This patch changes the state after PIO data-in to HSM_ST_IDLE instead of HSM_ST_LAST for accuracy. Signed-off-by: Albert Lee [EMAIL PROTECTED] Is this still needed? Not quite needed; it only makes the state transition after reading the last PIO block more accurate. However, if we want to do part of the irq PIO in the workqueue sometime in the future, this patch will be needed (otherwise the HSM might think it expecting another irq). For the time being, maybe we can just skip this patch until sometime it's really needed. -- albert - 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: sil24 PMP works with ST3500641AS but not HDS721010KLA330
On Wed, Oct 03, 2007 at 12:30:08PM +0900, Tejun Heo wrote: 1. Does booting with fewer number of drives (say 5) help? Boot is ok with 10 drives now with your latest code (20070808 instead of 20070803) 2. Does limiting PHY speed to 1.5Gbps using DIP switch on the harddrive help? Those drives do not have any DIP switches at all. Can I limit this in software in the driver maybe? Marc -- A mouse is a device used to point at the xterm you want to type in - A.S.R. Microsoft is to operating systems security what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ - 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
