Re: 2.6.23-rc7 - _random_ IRQ23 : nobody cared
Hi David, On Mon, 24 Sep 2007 23:56:59 +0930 David Newall <[EMAIL PROTECTED]> wrote: > Paul Rolland "(???) wrote: > > Hell, IRQ 23 is shared between libata and my modem !!! > > > > Tried using the modem? When no problem is reported, both the libata part and the modem are OK. When the problem is reported, at that time, only libata is handling IRQ23 (the modem is a WinModem, and the driver is an out-kernel module), this is still kernel boot time, and the disabling of the IRQ makes my machine unable to complete the boot process (too many disk timeout). It could be good to be able to delay the disabling of an IRQ something long enough to allow all the modules to be loaded... Paul - 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] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Peer Chen wrote: Add the ahci controller legacy mode support to sata_nv. Move the DIDs of legacy mode from ahci.c to sata_nv.c The patch base on kernel 2.6.23-rc8 Signed-off-by: Peer Chen <[EMAIL PROTECTED]> I don't understand why these are being moved? If an interface can be driven via the AHCI driver, that is greatly preferred over the sata_nv driver. 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: Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
We have three mode for one controller - IDE/RAID/AHCI, we want sata_nv being load when user select the IDE mode in BIOS, load ahci driver if RAID/AHCI being selected, which will verify if our legacy mode work well and have additional option if there is any bug for the ahci mode. Peer Chen 2007-09-25 - ·¢¼þÈË£ºJeff Garzik ·¢ËÍÈÕÆÚ£º2007-09-25 15:08:45 ÊÕ¼þÈË£ºPeer Chen ³ËÍ£ºlinux-kernel; linux-ide; akpm Ö÷Ì⣺Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv Peer Chen wrote: > Add the ahci controller legacy mode support to sata_nv. > Move the DIDs of legacy mode from ahci.c to sata_nv.c > > The patch base on kernel 2.6.23-rc8 > > Signed-off-by: Peer Chen <[EMAIL PROTECTED]> I don't understand why these are being moved? If an interface can be driven via the AHCI driver, that is greatly preferred over the sata_nv driver. 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] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Peer Chen wrote: We have three mode for one controller - IDE/RAID/AHCI, we want sata_nv being load when user select the IDE mode in BIOS, load ahci driver if RAID/AHCI being selected, which will verify if our legacy mode work well and have additional option if there is any bug for the ahci mode. I understand that logic, but look at what happens in practice: 1) User installs new OS in AHCI mode. Distro updates initramfs (loaded at kernel boot time, with boot drivers) to include ahci driver. 2) User reboots into BIOS setup, and switches from AHCI mode to IDE mode. 3) BIOS setup reboots computer. 4) OS kernel and initramfs image are loaded. ahci driver load fails. 5) User is left without a bootable system. The same situation happens in reverse, if you install in IDE mode (sata_nv in initramfs), and then switch to AHCI/RAID mode. Additionally, AHCI provides better performance and more direct exposure to the SATA frames. This is key for supporting many modern SATA features that cannot be accessed via IDE legacy mode. AHCI lacks in-silicon simulation of an IDE interface, which time has shown is a less stable, edge-case-prone approach to SATA. I do not find the "verify nvidia's legacy mode works" argument compelling; that is not the kernel's job, nor the user's. And if there is an AHCI silicon bug, let us deal with that when such a bug appears. Overall, AFAICS this patch -introduces- new ways for the user to easily render their systems unbootable. 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: Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv
Yes,I hear what you are saying but user should know what they are setting in BIOS,there are lots of ways to change the BIOS setting result in unbootable system not only change AHCI/IDE mode. If they encounter booting failure after changing the BIOS setting,they should restore it. Using legacy driver for legacy mode won't affect user to enjoy the feature of AHCI,just select AHCI/RAID mode will ok. As I know, Intel did it in the same way,and I think it's reasonable. -- Peer Chen 2007-09-25 - ·¢¼þÈË£ºJeff Garzik ·¢ËÍÈÕÆÚ£º2007-09-25 16:13:52 ÊÕ¼þÈË£ºPeer Chen ³ËÍ£ºlinux-kernel; linux-ide; akpm Ö÷Ì⣺Re: [PATCH] sata_nv,ahci: add the ahci legacy mode support to sata_nv Peer Chen wrote: > We have three mode for one controller - IDE/RAID/AHCI, we want sata_nv being > load when user select the IDE mode in BIOS, load ahci driver if RAID/AHCI > being selected, which will verify if our legacy mode work well and have > additional option if there is any > bug for the ahci mode. I understand that logic, but look at what happens in practice: 1) User installs new OS in AHCI mode. Distro updates initramfs (loaded at kernel boot time, with boot drivers) to include ahci driver. 2) User reboots into BIOS setup, and switches from AHCI mode to IDE mode. 3) BIOS setup reboots computer. 4) OS kernel and initramfs image are loaded. ahci driver load fails. 5) User is left without a bootable system. The same situation happens in reverse, if you install in IDE mode (sata_nv in initramfs), and then switch to AHCI/RAID mode. Additionally, AHCI provides better performance and more direct exposure to the SATA frames. This is key for supporting many modern SATA features that cannot be accessed via IDE legacy mode. AHCI lacks in-silicon simulation of an IDE interface, which time has shown is a less stable, edge-case-prone approach to SATA. I do not find the "verify nvidia's legacy mode works" argument compelling; that is not the kernel's job, nor the user's. And if there is an AHCI silicon bug, let us deal with that when such a bug appears. Overall, AFAICS this patch -introduces- new ways for the user to easily render their systems unbootable. 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: libata broken on Pegasos PPC platform (was: Re: IDE broken on Pegasos PPC platform)
On Mon, Sep 24, Alan Cox wrote: > hopefully that means the hack in the old VIA driver can also be killed > off. Not that I know. But I did not browse the IDE core long enough to figure out how to assign both irqs in a generic way. - 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: IDE broken on Pegasos PPC platform
On Mon, 2007-09-24 at 22:27 +0100, Matt Sealey wrote: > Yeah I'll ack it if it matters, although I'd make a nit about the > fixing of device tree entries in prom_init and have it moved to > nvramrc or a Forth script or boot loader.. > > Pegasos IDE quirks have been "fixed" so many times now in Linux, > this code's going to get reshuffled again in other changes, I > think the device tree should be fixed at the firmware level and > not in the kernel. In that case though, OF contains correct values for the interrupts, it's more of an issue related to the device being in legacy mode and the pci_dev only carrying one interrupt anyway. Ben. - 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/2] Enable link power management for ata drivers
> It converts several macros to inline functions (encouraged), and also > illustrates a nice, clean way of testing an ID word's validity. > [obviously the final implementation varies, depending on that ID word's > history] Its in -mm and I thought you put a copy in your tree after I said it hadn't upset anything in -mm ? 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
sata 1,2,3 - how can I tell ?
Hello Is there a way to know whether a disk is sata 1 2 or 3 ? I tried : sdparm -a -v , looked at dmesg , tried smartctl . thank you -- Raz - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sata 1,2,3 - how can I tell ?
Raz wrote: Is there a way to know whether a disk is sata 1 2 or 3 ? That is a marketing invention. At a technical level, there is no such thing as sata 1, 2, or 3. 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: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Jeff Garzik wrote: > The first step would be to clone the "upstream" branch of > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git > > and see if the problem is reproducible there. If yes, then you have > narrowed down the problem to something my ATA devel tree has introduced > into -mm. Nope, you're off the hook. The libata tree works great, so it must be something else in -mm conflicting. - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
On Tue, Sep 25 2007, Berck E. Nash wrote: > Jeff Garzik wrote: > > > The first step would be to clone the "upstream" branch of > > git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git > > > > and see if the problem is reproducible there. If yes, then you have > > narrowed down the problem to something my ATA devel tree has introduced > > into -mm. > > Nope, you're off the hook. The libata tree works great, so it must be > something else in -mm conflicting. Can you try 2.6.23-rc8 plus this patch: http://brick.kernel.dk/git-block.patch.bz2 and see if that works? -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Jens Axboe wrote: > On Tue, Sep 25 2007, Berck E. Nash wrote: >> Jeff Garzik wrote: >> >>> The first step would be to clone the "upstream" branch of >>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git >>> >>> and see if the problem is reproducible there. If yes, then you have >>> narrowed down the problem to something my ATA devel tree has introduced >>> into -mm. >> Nope, you're off the hook. The libata tree works great, so it must be >> something else in -mm conflicting. Whoops, sorry! I just lied. I'm a git newbie, and failed to actually get the "upstream" branch the first time, so rc8 is clean, but it fails when I actually pull the upstream branch. I'll git bisect and get back to you. BErck - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
On Tue, Sep 25 2007, Berck E. Nash wrote: > Jens Axboe wrote: > > On Tue, Sep 25 2007, Berck E. Nash wrote: > >> Jeff Garzik wrote: > >> > >>> The first step would be to clone the "upstream" branch of > >>> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git > >>> > >>> and see if the problem is reproducible there. If yes, then you have > >>> narrowed down the problem to something my ATA devel tree has introduced > >>> into -mm. > >> Nope, you're off the hook. The libata tree works great, so it must be > >> something else in -mm conflicting. > > Whoops, sorry! I just lied. I'm a git newbie, and failed to actually > get the "upstream" branch the first time, so rc8 is clean, but it fails > when I actually pull the upstream branch. I'll git bisect and get back > to you. OK, you probably realize this, but you can forget about the git-block testing for now then. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Jeff Garzik wrote: > Once the blame has been squared fixed upon me :) you can use git-bisect > to locate the precise change that broke your setup. Okay, here's the problem: 268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit commit 268fe6f9f15551be9abedd44a237392675d529d5 Author: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri Sep 21 07:09:36 2007 -0400 [libata] SCSI: simple TEST UNIT READY simulation It's trivial to ping the device, and that's a much more sane behavior than no-op. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> :04 04 44d34cdad073bd623545b8239aca9a113652c6d0 df6d21f7ce56a4e796f8f856c1f647b0395ab4df M drivers Berck - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Berck E. Nash wrote: Jeff Garzik wrote: Once the blame has been squared fixed upon me :) you can use git-bisect to locate the precise change that broke your setup. Okay, here's the problem: 268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit commit 268fe6f9f15551be9abedd44a237392675d529d5 Author: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri Sep 21 07:09:36 2007 -0400 [libata] SCSI: simple TEST UNIT READY simulation It's trivial to ping the device, and that's a much more sane behavior than no-op. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> :04 04 44d34cdad073bd623545b8239aca9a113652c6d0 df6d21f7ce56a4e796f8f856c1f647b0395ab4df M drivers Thanks for debugging! Can you tell me something about this device? [ 49.045635] ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133 [ 49.051677] ata2.00: 640 sectors, multi 1: LBA [ 49.056321] ata2.00: configured for UDMA/133 It seems like it does not support the 'check power mode' command. Can you post a text file attachment, containing the output of 'hdparm --Istdout' ? 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: libata not working for sis5533
Chuck Ebbert ha scritto: > On 08/31/2007 06:20 PM, Patrizio Bassi wrote: > >> Patrizio Bassi ha scritto: >> >>> Michal Piotrowski ha scritto: >>> Hi, [Adding IDE wizards to CC] On 26/08/07, Patrizio Bassi <[EMAIL PROTECTED]> wrote: > My sis630 chipset shipped with Asus A1000 > doesn't work properly with suspend with ide drivers > (http://bugzilla.kernel.org/show_bug.cgi?id=7077) > > i tried to switch to libata but i cannot boot. > I've enabled generic ide and sis specific code, both in-kernel. of > course scsi too. > > when i boot i get: irq #14 nobody cared and stop > > i have to remove battery to reboot pc. > I'm using 2.6.22.5, but i never got any libata kernel working. > > Patrizio > > ps. i'm writing from my desktop as i'm doing hardware mainteinance on > the laptop and could not boot it > > Please CC me. > > lspci: > 00:00.0 Host bridge: Silicon Integrated Systems [SiS] 630 Host (rev 11) > 00:00.1 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev > d0) > 00:01.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC > Bridge) > 00:01.1 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 > PCI Fast Ethernet (rev 80) > 00:01.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 > Controller (rev 07) > 00:01.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 > Controller (rev 07) > 00:01.4 Multimedia audio controller: Silicon Integrated Systems [SiS] > SiS PCI Audio Accelerator (rev 01) > 00:01.6 Modem: Silicon Integrated Systems [SiS] AC'97 Modem > Controller (rev a0) > 00:02.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual > PCI-to-PCI bridge (AGP) > 00:0a.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) > 00:0a.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80) > 01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] > 630/730 PCI/AGP VGA Display Adapter (rev 11) > > Regards, Michal >> i've been out for a week, but found no notice, did i lost any email or >> no activity on this issue? >> >> > > I assume you tried the standard workarounds, like > > pci=nommconf,nomsi > pci=noacpi > pci=biosirq > > (one at at time, not all at once.) > > > i just fineshed to try (had an hardware problem, could not be faster) but got no results :( libata is unusable on my system. i'll wait 2.6.23 to be out to try again. -- Patrizio Bassi www.patriziobassi.it - 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_sis: add missing UDMA5 timing value in sis_66_set_dmamode()
On 09/21/2007 03:29 AM, Tejun Heo wrote:
> sis_66_set_dmamode() also handles early UDMA100 (SIS630 ET) but is
> missing udma timing value for UDMA100. According to sis5513, this
> should be 0x8000. This caused UDMA100 device to fail on pata_sis till
> it downgrades to UDMA66 while it works fine on sis5513 at UDMA100.
>
> Reported by Adam Blech.
>
> Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
> Cc: Adam Blech <[EMAIL PROTECTED]>
> ---
> drivers/ata/pata_sis.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c
> index da3f720..3b5be77 100644
> --- a/drivers/ata/pata_sis.c
> +++ b/drivers/ata/pata_sis.c
> @@ -376,8 +376,9 @@ static void sis_66_set_dmamode (struct ata_port *ap,
> struct ata_device *adev)
> int drive_pci = sis_old_port_base(adev);
> u16 timing;
>
> + /* MWDMA 0-2 and UDMA 0-5 */
> const u16 mwdma_bits[] = { 0x008, 0x302, 0x301 };
> - const u16 udma_bits[] = { 0xF000, 0xD000, 0xB000, 0xA000, 0x9000};
> + const u16 udma_bits[] = { 0xF000, 0xD000, 0xB000, 0xA000, 0x9000,
> 0x8000 };
>
> pci_read_config_word(pdev, drive_pci, &timing);
>
Is this going into 2.6.23?
It's not in 2.6.23-rc8-mm1...
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Jeff Garzik wrote: > Can you tell me something about this device? > > [ 49.045635] ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133 > [ 49.051677] ata2.00: 640 sectors, multi 1: LBA > [ 49.056321] ata2.00: configured for UDMA/133 > > It seems like it does not support the 'check power mode' command. > > Can you post a text file attachment, containing the output of 'hdparm > --Istdout' ? No problem. The device in question is a Western Digital Raptor WD360GD 36.7GB 10,000 RPM Serial ATA150 Hard Drive. hdparm output attached. Berck - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Jeff Garzik wrote: Berck E. Nash wrote: Jeff Garzik wrote: Once the blame has been squared fixed upon me :) you can use git-bisect to locate the precise change that broke your setup. Okay, here's the problem: 268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit commit 268fe6f9f15551be9abedd44a237392675d529d5 Author: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri Sep 21 07:09:36 2007 -0400 [libata] SCSI: simple TEST UNIT READY simulation It's trivial to ping the device, and that's a much more sane behavior than no-op. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> :04 04 44d34cdad073bd623545b8239aca9a113652c6d0 df6d21f7ce56a4e796f8f856c1f647b0395ab4df M drivers Thanks for debugging! Can you tell me something about this device? [ 49.045635] ata2.00: ATA-6: Config Disk, RGL10364, max UDMA/133 [ 49.051677] ata2.00: 640 sectors, multi 1: LBA [ 49.056321] ata2.00: configured for UDMA/133 It seems like it does not support the 'check power mode' command. Can you post a text file attachment, containing the output of 'hdparm --Istdout' ? ATA spec says "The device shall return command aborted if the device does not support the Power Management feature set." Whereas TEST UNIT READY is required for SCSI. It seems the SAT authors didn't consider this case. I assume we can tell from the identify data that the device doesn't support power management and just fake success for TEST UNIT READY in this case? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Berck E. Nash wrote:
> hdparm output attached.
Whoops, it really is this time.
/dev/sde:
427a 3fff 0010 e100 0258 003f
000e 5744 2d57 4d41 4b48 3131 3235
3131 3700 0003 4000 004a 3331
2e30 3846 3331 5744 4320 5744 3336 3047
442d 3030 464c 4132 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
2f00 4001 0280 0007 3fff 0010
003f fc10 00fb 0110 44e0 044f 0007
0003 0078 0078 0078 0078
001f 0202
007e 74eb 7f63 4003 74e9 3e43 4003
407f 80fe
44e0 044f
0001 0141 0746
0002 0001
001f
001f
8da5
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Robert Hancock wrote: ATA spec says "The device shall return command aborted if the device does not support the Power Management feature set." Whereas TEST UNIT READY is required for SCSI. It seems the SAT authors didn't consider this case. Dumb me -- I misread that as mandatory. 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: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Berck E. Nash wrote: Jeff Garzik wrote: Once the blame has been squared fixed upon me :) you can use git-bisect to locate the precise change that broke your setup. Okay, here's the problem: 268fe6f9f15551be9abedd44a237392675d529d5 is first bad commit commit 268fe6f9f15551be9abedd44a237392675d529d5 Author: Jeff Garzik <[EMAIL PROTECTED]> Date: Fri Sep 21 07:09:36 2007 -0400 [libata] SCSI: simple TEST UNIT READY simulation It's trivial to ping the device, and that's a much more sane behavior than no-op. Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]> :04 04 44d34cdad073bd623545b8239aca9a113652c6d0 df6d21f7ce56a4e796f8f856c1f647b0395ab4df M drivers Does the attached patch change behavior at all? You should be able to apply it on top of libata-dev.git#upstream or -mm. If there are still problems, an updated dmesg (w/ the attached patch) and output from enabling ATA_DEBUG (include/linux/libata.h) would be very helpful. Thanks! Jeff diff --git a/drivers/ata/libata-scsi.c b/drivers/ata/libata-scsi.c index 3882c72..c9838f1 100644 --- a/drivers/ata/libata-scsi.c +++ b/drivers/ata/libata-scsi.c @@ -2800,7 +2800,9 @@ static inline ata_xlat_func_t ata_get_xlat_func(struct ata_device *dev, u8 cmd) return ata_scsi_start_stop_xlat; case TEST_UNIT_READY: - return ata_scsi_tur_xlat; + if (ata_id_has_pm(dev->id)) + return ata_scsi_tur_xlat; + return NULL; } return NULL; @@ -3021,6 +3023,7 @@ void ata_scsi_simulate(struct ata_device *dev, struct scsi_cmnd *cmd, case REZERO_UNIT: case SEEK_6: case SEEK_10: + case TEST_UNIT_READY: /* only for !PM devices */ ata_scsi_rbuf_fill(&args, ata_scsiop_noop); break;
Re: [PATCH] pata_sis: add missing UDMA5 timing value in sis_66_set_dmamode()
Tejun Heo wrote: sis_66_set_dmamode() also handles early UDMA100 (SIS630 ET) but is missing udma timing value for UDMA100. According to sis5513, this should be 0x8000. This caused UDMA100 device to fail on pata_sis till it downgrades to UDMA66 while it works fine on sis5513 at UDMA100. Reported by Adam Blech. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Cc: Adam Blech <[EMAIL PROTECTED]> --- drivers/ata/pata_sis.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) 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 UPDATED #upstream-fixes,#upstream] sata_sil24: fix IRQ clearing race when PCIX_IRQ_WOC is used
Tejun Heo wrote: When PCIX_IRQ_WOC is used, sil24 has an inherent race condition between clearing IRQ pending and reading IRQ status. If IRQ pending is cleared after reading IRQ status, there's possibility of lost IRQ. If IRQ pending is cleared before reading IRQ status, spurious IRQs will occur. sata_sil24 till now cleared IRQ pending after reading IRQ status thus losing IRQs on machines where PCIX_IRQ_WOC was used. Reverse the order and ignore spurious IRQs if PCIX_IRQ_WOC. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- The previous patch contained a stupid mistake. This is the correct one. drivers/ata/sata_sil24.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) 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
Polling (was Re: [PATCHSET 2/2] implement PMP support, take 6)
Here's one thing that jumps out at me, reviewing the PMP patchset: PMP reads and writes require polling, which is not something we should impose upon the design. Conversations with a port multiplier are fundamentally packetized, and modern controllers treat these just like the bazillion other types of packets they must deal with: just another entry on a DMA ring, with an interrupt to signal completion/reception. For situations like this, libata EH needs to the use normal, natural delivery method: initiate an action, and wait asynchronously for completion. Certainly the flow of control might be synchronous inside libata EH; that requirement is normal and usable with an issue+wait setup. More and more I am convinced this "mission creep", the slow expansion of polling even into modern controllers, is going in the wrong direction. Consider the mvsas driver (Marvell 6440 SAS/SATA), whose rough draft I posted yesterday: in order to support SAS wide ports -- multiple phys aggregated at runtime into a single "SAS port" -- and remote SATA device attachment behind expanders then PMPs, their hardware design became - single command queue, for all ports/phys - single response queue, for all ports/phys - events from all ports, SAS and SATA, aggregate onto those queues - a single MSI interrupt signals "go look for new work on DMA ring" There, even the concept of "port" is fluid, and the libata EH model of freezing and thawing a port (with the desired irq-off result) just doesn't fit the hardware. The model under SAS+SATA is even closer to that of a network driver: you just have a very dumb driver, that sends and receives frames, as signalled via interrupt. As such, polling is simply an outmoded concept. It does not make sense on new hardware, and forcing design decisions down that path only lead to a cascade of similar design decisions -- pmp_read polling being just one example of such a result. Just like the Linux kernel MM platform API presents 3 levels of page table entries, even when the hardware may only have 2, libata high level API _must_ be implemented as 100% asynchronous event driven API. If the default implementation chooses to use polling -- i.e. all SFF controllers -- that's fine. But in the new SAS/SATA world its clear that we have far too many polling-related assumptions as it is. Polling just flat out doesn't make sense on modern SAS/SATA -- and even a couple modern SATA controllers. On such controllers, we are notified immediately via interrupt even in the event of errors. 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: Just like the Linux kernel MM platform API presents 3 levels of page table entries, even when the hardware may only have 2, libata high level API _must_ be implemented as 100% asynchronous event driven API. To be more clear, non-taskfile packets/commands should be delivered via ->qc_issue, just like taskfiles. This is similar to sas_task in libsas, which can be a SATA packet, a SAS packet, a management packet, ... In the long run, we should probably look at integrating ata_queued_cmd and sas_task. Once ata_queued_cmd becomes multi-protocol (tf, pmp, sgpio, ...), it becomes more generic. sas_task is also multi-protocol. 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 01/12] libata: misc updates for AN
Tejun Heo wrote: Update AN support in preparation of PMP support. * s/ata_id_has_AN/ata_id_has_atapi_AN/ * add AN enabled reporting during configuration * add err_mask to AN configuration failure reporting * update LOCKING comment for ata_scsi_media_change_notify() * check whether ATA dev is attached to SCSI dev ata_scsi_media_change_notify() * set ATA_FLAG_AN in ahci and sata_sil24 Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Cc: Kriten Carlson Accardi <[EMAIL PROTECTED]> --- drivers/ata/ahci.c|2 +- drivers/ata/libata-core.c | 24 ++-- drivers/ata/libata-scsi.c |7 --- drivers/ata/sata_sil24.c | 13 +++-- include/linux/ata.h |2 +- 5 files changed, 31 insertions(+), 17 deletions(-) applied 1-12 - 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] sata_via: kill SATA_PATA_SHARING register handling
Tejun Heo wrote: The SATA_PATA_SHARING register doesn't have anything to do with the SATA part of the controller. It indicates whether an extern SATA PHY is attached to the PATA part of the controller and if so how it is wired. As the PATA part is driven by pata_via, sata_via has no reason to care about that. Also, pata_via should work fine under all configurations. This patch removes unnecessary attach failures. It seems recent via chipsets are defaulting to different values or are actually connected to SATA PHY triggering this more often. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- drivers/ata/sata_via.c | 16 ++-- 1 file changed, 2 insertions(+), 14 deletions(-) applied to #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: [PATCH #upstream] libata: fix ata_set_max_sectors()
Tejun Heo wrote: In ata_set_max_sectors(), the highest nibble in LBA28 mode was missing. This made drives sized between 8G and 128G with HPA turned on to be resized to under 8G. Fix it. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> --- This one fixes my dumb mistake. drivers/ata/libata-core.c |5 - 1 file changed, 4 insertions(+), 1 deletion(-) 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: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Berck E. Nash wrote: Jeff Garzik wrote: Does the attached patch change behavior at all? You should be able to apply it on top of libata-dev.git#upstream or -mm. Still broken, dmesg with ATA_DEBUG defined, attached. Great, this will be useful output. It will probably be a couple days before my next patch. In the meantime, you can extract the bad commit to a patch git-diff-tree -p 268fe6f9f15551be9abedd44a237392675d529d5 > \ /tmp/patch and then revert it locally in your kernel tree patch -sp1 -R < /tmp/patch to temporarily work around this. I will definitely make sure this is either fixed or reverted before it goes upstream to Linus. Thanks, 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 1/2] Enable link power management for ata drivers
Alan Cox wrote: It converts several macros to inline functions (encouraged), and also illustrates a nice, clean way of testing an ID word's validity. [obviously the final implementation varies, depending on that ID word's history] Its in -mm and I thought you put a copy in your tree after I said it hadn't upset anything in -mm ? it didn't apply straightaway to my tree for whatever reason, IIRC - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.23-rc6-mm1: Build failure on ppc64 drivers/ata/pata_scc.c
Satyam Sharma wrote: Hi, On Thu, 20 Sep 2007, Alan Cox wrote: On Thu, 20 Sep 2007 14:13:15 +0100 [EMAIL PROTECTED] (Mel Gorman) wrote: PPC64 building allmodconfig fails to compile drivers/ata/pata_scc.c . It doesn't show up on other arches because this driver is specific to the architecture. drivers/ata/pata_scc.c: In function `scc_bmdma_status' Its not been updated to match the libata core changes. Try something like this. Whoever is maintaining it should also remove the prereset cable handling code and use the proper cable detect method. It appears you forgot to fix scc_std_softreset() and one of its callsites in scc_bdma_stop(). A complete patch is attempted below -- please review. [PATCH -mm] pata_scc: Keep up with libata core API changes Little fixlets, that the build started erroring / warning about: drivers/ata/pata_scc.c: In function 'scc_bmdma_status': drivers/ata/pata_scc.c:734: error: structure has no member named 'active_tag' drivers/ata/pata_scc.c: In function 'scc_pata_prereset': drivers/ata/pata_scc.c:866: warning: passing arg 1 of 'ata_std_prereset' from incompatible pointer type drivers/ata/pata_scc.c: In function 'scc_error_handler': drivers/ata/pata_scc.c:908: warning: passing arg 2 of 'ata_bmdma_drive_eh' from incompatible pointer type drivers/ata/pata_scc.c:908: warning: passing arg 3 of 'ata_bmdma_drive_eh' from incompatible pointer type drivers/ata/pata_scc.c:908: warning: passing arg 5 of 'ata_bmdma_drive_eh' from incompatible pointer type make[2]: *** [drivers/ata/pata_scc.o] Error 1 Signed-off-by: Satyam Sharma <[EMAIL PROTECTED]> Cc: Alan Cox <[EMAIL PROTECTED]> Cc: Mel Gorman <[EMAIL PROTECTED]> --- Andrew, this includes (supercedes) the previous two ones from Mel / Alan. drivers/ata/pata_scc.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) 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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Zoltan Boszormenyi wrote:
Hi,
Jeff Garzik írta:
[EMAIL PROTECTED] wrote:
From: Kuan Luo <[EMAIL PROTECTED]>
Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller. NCQ function is disable by default, you can enable it with
'swncq=1'. NCQ will be turned off if the drive is Maxtor on MCP51 or
MCP55
rev 0xa2 platform.
[EMAIL PROTECTED]: build fix]
Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
Cc: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ata/sata_nv.c | 860 +++-
1 files changed, 851 insertions(+), 9 deletions(-)
I finally gave this a thorough review.
Overall, good work. The state transitions all seem solid. I made
several minor changes and cleanups, and checked it into the 'nv-swncq'
branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
Two hurdles before I'm ready to push upstream:
* someone please verify my minor changes did not break anything; I
don't have real hardware
After reading the diff between the original and your cleaned up version
it seems both the change from 4 individual flags to a single integer and
the
nv_swncq_bmdma_stop() -> __ata_bmdma_stop() transition are obviously
correct.
I attached a small cleanup patch which may make one check a bit more
readable.
However, can you explain this chunk below? Why isn't it needed?
@@ -615,7 +622,6 @@ static const struct ata_port_info nv_por
{
.sht= &nv_swncq_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
- .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
that's a bug. fixed.
I also applied your cleanup.
-
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: enable GHC.AE bit before set GHC.HR
Peer Chen wrote:
According to the description of section 5.2.2.1 and 10.1.2 of AHCI
specification rev1_1/rev1_2, GHC.HR shall only be set to ¡®1¡¯
by software when GHC.AE is set to ¡®1¡¯.
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-20 11:07:31.0 -0400
@@ -834,6 +834,10 @@ static int ahci_reset_controller(struct
void __iomem *mmio = host->iomap[AHCI_PCI_BAR];
u32 tmp;
+/* turn on AHCI mode before controller reset*/
+writel(HOST_AHCI_EN, mmio + HOST_CTL);
+(void) readl(mmio + HOST_CTL); /* flush */
applied the attached patch, inspired by yours.
commit 5fca365d6109b51cfeb3515ca660cd2dc6e8822c
Author: Jeff Garzik <[EMAIL PROTECTED]>
Date: Wed Sep 26 00:02:41 2007 -0400
[libata] AHCI: enable AHCI mode, before using AHCI reset
AHCI spec says host-reset bit may only be set when the ahci-enable bit
is also set.
Noticed by Peer Chen <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
drivers/ata/ahci.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
5fca365d6109b51cfeb3515ca660cd2dc6e8822c
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 9f3c591..b615390 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -827,8 +827,14 @@ static int ahci_reset_controller(struct ata_host *host)
void __iomem *mmio = host->iomap[AHCI_PCI_BAR];
u32 tmp;
- /* global controller reset */
+ /* we must be in AHCI mode, before using anything
+* AHCI-specific, such as HOST_RESET.
+*/
tmp = readl(mmio + HOST_CTL);
+ if (!(tmp & HOST_AHCI_EN))
+ writel(tmp | HOST_AHCI_EN, mmio + HOST_CTL);
+
+ /* global controller reset */
if ((tmp & HOST_RESET) == 0) {
writel(tmp | HOST_RESET, mmio + HOST_CTL);
readl(mmio + HOST_CTL); /* flush */
Re: 2.6.23-rc7-mm1 AHCI ATA errors -- won't boot
Would it also be possible for you to send along 'hdparm --Istdout' output for your config disk thingy, /dev/sdd ? 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
[git patches] libata fixes
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/pata_sis.c |3 ++-
drivers/ata/sata_sil24.c | 16
2 files changed, 14 insertions(+), 5 deletions(-)
Tejun Heo (2):
sata_sil24: fix IRQ clearing race when PCIX_IRQ_WOC is used
pata_sis: add missing UDMA5 timing value in sis_66_set_dmamode()
diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c
index 2bd7645..cce2834 100644
--- a/drivers/ata/pata_sis.c
+++ b/drivers/ata/pata_sis.c
@@ -375,8 +375,9 @@ static void sis_66_set_dmamode (struct ata_port *ap, struct
ata_device *adev)
int drive_pci = sis_old_port_base(adev);
u16 timing;
+ /* MWDMA 0-2 and UDMA 0-5 */
const u16 mwdma_bits[] = { 0x008, 0x302, 0x301 };
- const u16 udma_bits[] = { 0xF000, 0xD000, 0xB000, 0xA000, 0x9000};
+ const u16 udma_bits[] = { 0xF000, 0xD000, 0xB000, 0xA000, 0x9000,
0x8000 };
pci_read_config_word(pdev, drive_pci, &timing);
diff --git a/drivers/ata/sata_sil24.c b/drivers/ata/sata_sil24.c
index ef83e6b..233e886 100644
--- a/drivers/ata/sata_sil24.c
+++ b/drivers/ata/sata_sil24.c
@@ -888,6 +888,16 @@ static inline void sil24_host_intr(struct ata_port *ap)
u32 slot_stat, qc_active;
int rc;
+ /* If PCIX_IRQ_WOC, there's an inherent race window between
+* clearing IRQ pending status and reading PORT_SLOT_STAT
+* which may cause spurious interrupts afterwards. This is
+* unavoidable and much better than losing interrupts which
+* happens if IRQ pending is cleared after reading
+* PORT_SLOT_STAT.
+*/
+ if (ap->flags & SIL24_FLAG_PCIX_IRQ_WOC)
+ writel(PORT_IRQ_COMPLETE, port + PORT_IRQ_STAT);
+
slot_stat = readl(port + PORT_SLOT_STAT);
if (unlikely(slot_stat & HOST_SSTAT_ATTN)) {
@@ -895,9 +905,6 @@ static inline void sil24_host_intr(struct ata_port *ap)
return;
}
- if (ap->flags & SIL24_FLAG_PCIX_IRQ_WOC)
- writel(PORT_IRQ_COMPLETE, port + PORT_IRQ_STAT);
-
qc_active = slot_stat & ~HOST_SSTAT_ATTN;
rc = ata_qc_complete_multiple(ap, qc_active, sil24_finish_qc);
if (rc > 0)
@@ -910,7 +917,8 @@ static inline void sil24_host_intr(struct ata_port *ap)
return;
}
- if (ata_ratelimit())
+ /* spurious interrupts are expected if PCIX_IRQ_WOC */
+ if (!(ap->flags & SIL24_FLAG_PCIX_IRQ_WOC) && ata_ratelimit())
ata_port_printk(ap, KERN_INFO, "spurious interrupt "
"(slot_stat 0x%x active_tag %d sactive 0x%x)\n",
slot_stat, ap->active_tag, ap->sactive);
-
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
Chipset selection for NCQ md RAID
Given the current kernel (2.6.22.8), which SATA chipset would you feel most comfortable plugging in to achieve: - 16 1TB Hitachi 7K1000 drives - NCQ support - Kernel md RAID (ie hardware RAID not necessary) - Max transfer rate to OS (PCIe should handle 16 drives given their current transfer rate?) (Assuming the required number of chips of any chipset could be made available on the bus.) If support for SiI chips is the most robust, would multiple SiI3124/SiI3132 chips be most reliable? Or is support for something like a Marvell 88SX6081 good enough so that only 2 chips are needed?. I have not owned any of these chips, and my impression is that the SiI chips have some of the most robust support. The comments at the top of sata_mv.c scare me, even if they might be out of date... :) What about port multiplier support? Do they ever introduce stability problems with the drivers? Is native libata support for high-density Areca cards planned? Does anyone know if the manufacturer driver is good enough to rely on for the above config to "just work"? I'd personally like to stay within libata. (Comments from any Areca Linux users with an ARC-1261ML? http://www.areca.com.tw/products/pcie341.htm) Thanks in advance, -Andrew - 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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Jeff Garzik írta:
Zoltan Boszormenyi wrote:
Hi,
Jeff Garzik írta:
[EMAIL PROTECTED] wrote:
From: Kuan Luo <[EMAIL PROTECTED]>
Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller. NCQ function is disable by default, you can enable it
with
'swncq=1'. NCQ will be turned off if the drive is Maxtor on MCP51
or MCP55
rev 0xa2 platform.
[EMAIL PROTECTED]: build fix]
Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
Cc: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ata/sata_nv.c | 860 +++-
1 files changed, 851 insertions(+), 9 deletions(-)
I finally gave this a thorough review.
Overall, good work. The state transitions all seem solid. I made
several minor changes and cleanups, and checked it into the
'nv-swncq' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
Two hurdles before I'm ready to push upstream:
* someone please verify my minor changes did not break anything; I
don't have real hardware
After reading the diff between the original and your cleaned up version
it seems both the change from 4 individual flags to a single integer
and the
nv_swncq_bmdma_stop() -> __ata_bmdma_stop() transition are obviously
correct.
I attached a small cleanup patch which may make one check a bit more
readable.
However, can you explain this chunk below? Why isn't it needed?
@@ -615,7 +622,6 @@ static const struct ata_port_info nv_por
{
.sht= &nv_swncq_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
- .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
that's a bug. fixed.
I also applied your cleanup.
Thanks, but you took the wrong cleanup patch.
My original, i.e. this chunk below is wrong.
@@ -2291,8
+2283,7
@@ static void nv_swncq_host_interrupt(struct ata_port *ap, u16 fis)
*/
pp->dhfis_bits |= (0x1 << pp->last_issue_tag);
pp->ncq_flags |= ncq_saw_d2h;
- if ((pp->ncq_flags & ncq_saw_sdb) ||
- (pp->ncq_flags & ncq_saw_backout)) {
+ if (pp->ncq_flags & (ncq_saw_sdb || ncq_saw_backout)) {
ata_ehi_push_desc(ehi, "illegal fis transaction");
ehi->err_mask |= AC_ERR_HSM;
ehi->action |= ATA_EH_HARDRESET;
It should be a binary OR between the flags. This caused immediate
NCQ errors upon boot and lead to disabling NCQ.
My second patch has it corrected.
Best regards,
Zoltán Böszörményi
-
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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Zoltan Boszormenyi wrote:
Jeff Garzik írta:
Zoltan Boszormenyi wrote:
Hi,
Jeff Garzik írta:
[EMAIL PROTECTED] wrote:
From: Kuan Luo <[EMAIL PROTECTED]>
Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller. NCQ function is disable by default, you can enable it
with
'swncq=1'. NCQ will be turned off if the drive is Maxtor on MCP51
or MCP55
rev 0xa2 platform.
[EMAIL PROTECTED]: build fix]
Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
Cc: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ata/sata_nv.c | 860 +++-
1 files changed, 851 insertions(+), 9 deletions(-)
I finally gave this a thorough review.
Overall, good work. The state transitions all seem solid. I made
several minor changes and cleanups, and checked it into the
'nv-swncq' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
Two hurdles before I'm ready to push upstream:
* someone please verify my minor changes did not break anything; I
don't have real hardware
After reading the diff between the original and your cleaned up version
it seems both the change from 4 individual flags to a single integer
and the
nv_swncq_bmdma_stop() -> __ata_bmdma_stop() transition are obviously
correct.
I attached a small cleanup patch which may make one check a bit more
readable.
However, can you explain this chunk below? Why isn't it needed?
@@ -615,7 +622,6 @@ static const struct ata_port_info nv_por
{
.sht= &nv_swncq_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
- .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
that's a bug. fixed.
I also applied your cleanup.
Thanks, but you took the wrong cleanup patch.
My original, i.e. this chunk below is wrong.
@@ -2291,8
+2283,7
@@ static void nv_swncq_host_interrupt(struct ata_port *ap, u16 fis)
*/
pp->dhfis_bits |= (0x1 << pp->last_issue_tag);
pp->ncq_flags |= ncq_saw_d2h;
- if ((pp->ncq_flags & ncq_saw_sdb) ||
- (pp->ncq_flags & ncq_saw_backout)) {
+ if (pp->ncq_flags & (ncq_saw_sdb || ncq_saw_backout)) {
ata_ehi_push_desc(ehi, "illegal fis transaction");
ehi->err_mask |= AC_ERR_HSM;
ehi->action |= ATA_EH_HARDRESET;
It should be a binary OR between the flags. This caused immediate
NCQ errors upon boot and lead to disabling NCQ.
My second patch has it corrected.
fixed
-
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 05/25] ata: add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Jeff Garzik írta:
Zoltan Boszormenyi wrote:
Jeff Garzik írta:
Zoltan Boszormenyi wrote:
Hi,
Jeff Garzik írta:
[EMAIL PROTECTED] wrote:
From: Kuan Luo <[EMAIL PROTECTED]>
Add the Software NCQ support to sata_nv.c for MCP51/MCP55/MCP61 SATA
controller. NCQ function is disable by default, you can enable
it with
'swncq=1'. NCQ will be turned off if the drive is Maxtor on
MCP51 or MCP55
rev 0xa2 platform.
[EMAIL PROTECTED]: build fix]
Signed-off-by: Kuan Luo <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
Cc: Zoltan Boszormenyi <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
drivers/ata/sata_nv.c | 860
+++-
1 files changed, 851 insertions(+), 9 deletions(-)
I finally gave this a thorough review.
Overall, good work. The state transitions all seem solid. I made
several minor changes and cleanups, and checked it into the
'nv-swncq' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
Two hurdles before I'm ready to push upstream:
* someone please verify my minor changes did not break anything; I
don't have real hardware
After reading the diff between the original and your cleaned up
version
it seems both the change from 4 individual flags to a single
integer and the
nv_swncq_bmdma_stop() -> __ata_bmdma_stop() transition are
obviously correct.
I attached a small cleanup patch which may make one check a bit
more readable.
However, can you explain this chunk below? Why isn't it needed?
@@ -615,7 +622,6 @@ static const struct ata_port_info nv_por
{
.sht= &nv_swncq_sht,
.flags = ATA_FLAG_SATA | ATA_FLAG_NO_LEGACY,
- .link_flags = ATA_LFLAG_HRST_TO_RESUME,
.pio_mask = NV_PIO_MASK,
.mwdma_mask = NV_MWDMA_MASK,
.udma_mask = NV_UDMA_MASK,
that's a bug. fixed.
I also applied your cleanup.
Thanks, but you took the wrong cleanup patch.
My original, i.e. this chunk below is wrong.
@@ -2291,8
+2283,7
@@ static void nv_swncq_host_interrupt(struct ata_port *ap, u16 fis)
*/
pp->dhfis_bits |= (0x1 << pp->last_issue_tag);
pp->ncq_flags |= ncq_saw_d2h;
- if ((pp->ncq_flags & ncq_saw_sdb) ||
- (pp->ncq_flags & ncq_saw_backout)) {
+ if (pp->ncq_flags & (ncq_saw_sdb || ncq_saw_backout)) {
ata_ehi_push_desc(ehi, "illegal fis
transaction");
ehi->err_mask |= AC_ERR_HSM;
ehi->action |= ATA_EH_HARDRESET;
It should be a binary OR between the flags. This caused immediate
NCQ errors upon boot and lead to disabling NCQ.
My second patch has it corrected.
fixed
Thanks. And would you please also enable swncq by default? :-)
It's very stable.
Best regards,
Zoltán Böszörményi
-
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
