Hello,
> +void ata_irq_on(struct ata_port *ap)
> {
> struct ata_ioports *ioaddr = &ap->ioaddr;
> - u8 tmp;
>
> ap->ctl &= ~ATA_NIEN;
> ap->last_ctl = ap->ctl;
>
> iowrite8(ap->ctl, ioaddr->ctl_addr);
> - tmp = ata_wait_idle(ap);
> + ata_wait_idle(ap);
>
>
Albert Lee wrote:
> This patch let polling pio codes to use freeze()/thaw() for irq off/on.
> The reason is: some ATAPI devices raises INTRQ even of nIEN = 1.
> Using the host adapter irq mask mechanism, if available, is more reliable
> than the device nIEN bit.
>
> ata_qc_set_polling() is also r
Albert Lee wrote:
> With the previous changes made to tf_load(), ap->last_ctl is now unused.
> Remove it.
>
> (The purpose of ap->last_ctl is to cache the last status of nIEN bit
> and hopefully avoid writing the Control register unnecessarily.
> However, the libata polling code always call irq_o
Petr Vandrovec wrote:
> Hello,
> first let me thank you for your PMP code. Works great. Though I could not
> built it with ACPI disable - it is possible that I did merge wrong (I'm using
> your tree with current Linus's TOT), though I do not think. Patch is at
> the end.
It's my screw up. I
Hello,
first let me thank you for your PMP code. Works great. Though I could not
built it with ACPI disable - it is possible that I did merge wrong (I'm using
your tree with current Linus's TOT), though I do not think. Patch is at
the end.
If you are interested in success report, then my dmes
Simon Farnsworth wrote:
> Tejun Heo wrote:
>> Simon Farnsworth wrote:
>>> Tejun Heo wrote:
Simon Farnsworth wrote:
> Just a thought; is it possible to trigger libata EH from userspace? If
> so, we could write a small utility to disable write cache, then force EH
> to detect the cha
Hello,
David Shaw wrote:
>>> Starting with two 500GB SATA drives (interface card uses a Silicon
>>> 3124 chipset), /dev/sdd and /dev/sde. I partitioned each into two
>>> 250GB chunks (250*1000*1000*1000, not 250*1024*1024*1024), and set up
>>> two RAID 1 sets such that /dev/md0 is /dev/sdd1+/dev/
Jeff Garzik wrote:
Craig Block wrote:
Linux kernel: version 2.6.22.1
Chipset: VIA VT8363 + VT82C686A
Hard drives: Quantum Fireball LCT10 (UDMA66)
I'm having a problem with the 80-wire/40-wire cable detection in the
ata driver. Even when I configure the kernel with IDEDMA_IVB set, I
still g
Hello, I have a doubt... I have Debian 4.0 and the kernel 2.6.22
compiled by me, and now when I shutdown my machine, appears a message
telling that the devices (/dev/sda5 , 6 and so on..) are busy and
cannot be unmounted, and tells me that I must update my shutdown
utility... Then the system go ha
Hi.
I've run into a problem with the lastest kernel (2.6.22.1) and a drive set to
spinup on set_features.
..
ATA device, with non-removable media
powers-up in standby; SET FEATURES subcmd spins-up.
Model Number: WDC WD3200JS-57PDB0
Serial Number: X
Firmware Re
greg wrote:
dean gaudet arctic.org> writes:
if you've got any other workload you'd like me to throw at it,
let me know.
I've had a few problems with the driver in 2.6.20 (fc6xen x86_64). The machine
tended to lock up after a random period of time (from a few minutes upwards),
without any
On Fri, Jul 13, 2007 at 04:34:06PM +0900, Tejun Heo wrote:
> > It fails whether I use a raw /dev/sdd or partition it into one large
> > /dev/sdd1, or partition into multiple partitions. sata_sil24 seems to
> > work by itself, as does dm, but as soon as I mix sata_sil24+dm, I get
> > corruption.
>
> Since we're guessing (I assume?), I definitely want to make sure we have
> the correct MV variant for use with RocketRAID.
We are not guessing. There is sufficient information in the driver to
identify the specific chip variant
-
To unsubscribe from this list: send the line "unsubscribe linux-i
Mark?
Ryan Power wrote:
> Hi.
> I've run into a problem with the lastest kernel (2.6.22.1) and a drive
> set to spinup on set_features.
>
> hdparm reports:
> /dev/sdf:
>
> ATA device, with non-removable media
> powers-up in standby; SET FEATURES subcmd spins-up.
> Model Number: WDC
Henry Su wrote:
> From: henry.su+AEA-amd.com
>
> The sata controller device ID will be different according to the onchip
> sata type setting in system BIOS:
> Device Device
> ID
> SATA in IDE mode
Tejun Heo wrote:
> Mikael Pettersson wrote:
>> Albert's patch is OK as far as sata_promise is concerned, but
>> I want to see an update of libata.tmpl and libata-eh.c to
>> indicate the new, weakened, specification of freeze/thaw before
>> I ACK this patch.
Hmmm The docbook document is too sta
[EMAIL PROTECTED] wrote:
> Trying to upgrade from FC4 to F7. Linux version 2.6.14-1.1656_FC4.
> Sorry but don't know the F7 kernel specifics. If this is a propblem,
> I will get them for you. Have Kouwell 571-B PCI ATA-133 card with the
> Silicon Image 0680 chipset connected to two dvd drives. Bios
Jeff Garzik wrote:
> Tejun Heo wrote:
>> @@ -1698,12 +1705,13 @@ static void ahci_print_info(struct ata_host
>> *host)
>>
>> dev_printk(KERN_INFO, &pdev->dev,
>> "flags: "
>> - "%s%s%s%s%s%s"
>> - "%s%s%s%s%s%s%s\n"
>> +"%s%s%s%s%s%s%s"
>> +
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if
DMA is
> >>not complete or interrupt pending, it may wait 10 more secs...
>
> > I really don't remember... :)
>
> > Maybe Mark or Alan could help with figuring this out.
>
> They also have probably forgotten. :-)
Alan Cox wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs, and if DMA is
not complete or interrupt pending, it may wait 10 more secs...
I really don't remember... :)
Maybe Mark or Alan could help with figuring this out.
They also have probably forgotten. :-)
Be
Hello.
Mark Lord wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs,
and if DMA is
not complete or interrupt pending, it may wait 10 more secs...
I really don't remember... :)
Maybe Mark or Alan could help with figuring this out.
They also have probably forg
Hello.
Bartlomiej Zolnierkiewicz wrote:
* Add DRV_NAME define and use it instead of sgiioc4_chipset.name.
* Remove no longer needed sgiioc4_chipset.
* Remove needless clearing of ->atapi_dma from ide_dma_sgiioc4().
* Fix ide_dma_sgiioc4() to return success/failure. Check return value
Bartlomiej Zolnierkiewicz wrote:
* Fix cs5535_tuneproc() to pass PIO transfer mode value instead of PIO mode
number to cs5535_set_speed() (fixes random PIO timings being programmed
and a possible OOPS). Do a little cleanup while at it.
* Fix cs5535_set_speed() to check if the mate device
I see this on boot with kernels 2.6.22.1 and 2.6.20.15:
ata1: D2H reg with I during NCQ, this message won't be printed again
But I can't find anything that tells me what it means, or whether
it's a real problem.
x86_64 kernel with controller:
00:1f.2 SATA controller: Intel Corporation
> +++ linux-powerpc-git.mod/drivers/ata/pata_scc.c 2007-07-10
> 17:13:01.0 +0900
> @@ -238,6 +238,12 @@ static void scc_set_dmamode (struct ata_
> else
> offset = 0; /* 100MHz */
>
> + /* errata A308 workaround: limit ATAPI UDMA mode to UDMA4 */
> + i
Hello.
Bartlomiej Zolnierkiewicz wrote:
* Add { 0, 0 } entry to {kauai,shasta}_pio_timings[] so kauai_lookup_timing()
always returns a valid PIO timing (fixes PIO timing not being set for devices
with minimum PIO cycle <= 120ns).
Ugh... the way those tables are following each other, th
Hello.
Akira Iguchi wrote:
Workaround for errata A308: turn down the UDMA mode and retry
the DMA command when the data lost condition is detected.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]>
---
diff -purN -X linux-powerpc-git/Documentati
Bartlomiej Zolnierkiewicz wrote:
* Use ide_tune_dma() in amd74xx/via82cxxx driver, this fixes following bugs:
- DMA capability bit not being checked on the device
- DMA blacklist not being checked
- DMA mode being programmed even if drive->autodma == 0
(thus possibly destroying PIO tim
> >>Craig Block wrote:
> >>
> >>I'm having a problem with the 80-wire/40-wire cable detection
> Jeff Garzik wrote:
> >
> >If you signal a 40-wire cable too fast, you get trouble with a
> >capital T.
Thanks everyone for graciously replying to my negative email. I was
pretty irritated when I found
Sergei Shtylyov wrote:
Mark Lord wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20 secs,
and if DMA is not complete or interrupt pending, it may wait 10 more secs...
..
I've lost the original question from this thread, but the idea of the
The original question concer
Mark Lord wrote:
I've lost the original question from this thread, but the idea of the
The original question concerned specifically the DMA command
timeout which is twice more than the usual one, WAIT_CMD (10 seconds).
longish
timeouts was that drive *may* be spun down ("standby"), and
Sergei Shtylyov wrote:
Mark Lord wrote:
The original question concerned specifically the DMA command
timeout which is twice more than the usual one, WAIT_CMD (10 seconds).
..
When a drive is in standby, we don't send it anything special to wake up.
So even DMA commands have to have a long
Mark Lord wrote:
O> >>BTW, why the timeout is so damn long? 2*WAIT_CMD is 20
secs, and if DMA is not complete or interrupt pending, it may wait
10 more secs...
..
I've lost the original question from this thread, but the idea of the
The original question concerned specifically th
Mark Lord wrote:
The original question concerned specifically the DMA command
timeout which is twice more than the usual one, WAIT_CMD (10 seconds)...
When a drive is in standby, we don't send it anything special to wake
up.
So even DMA commands have to have a long enough timeout to allow
Sergei Shtylyov wrote:
Mark Lord wrote:
..
When a drive is in standby, we don't send it anything special to wake up.
Wait, aren't we sending IDLE on resume step 2 -- looking at
ide-io.cide_start_power_step()?
Sure, for RESUME.
But now for a drive that just happens to have put itself in
Sergei Shtylyov wrote:
Mark Lord wrote:
..
I would guess simply because DMA has to transfer up to 256 sectors of
data,
possibly with sector reallocations, in addition to waiting for the drive
to spin up. Other commands don't.
What?! PIO commands don't have to do this as well? :-)
"Other
Mark Lord wrote:
Sergei Shtylyov wrote:
Mark Lord wrote:
..
When a drive is in standby, we don't send it anything special to wake
up.
Wait, aren't we sending IDLE on resume step 2 -- looking at
ide-io.cide_start_power_step()?
Sure, for RESUME.
But now for a drive that just happens to
On Wednesday 11 July 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
>
> Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
added
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a
On Thursday 12 July 2007, Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
>
> > * Add sis5513_ata133_udma_filter() for chipset_family >= ATA_133,
> > use it to filter UDMA6 mode if ATA133 bit is disabled.
>
> > * Remove no longer needed UDMA6 limiting logic from sis5513_tu
On Friday 13 July 2007, Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
>
> > * Add DRV_NAME define and use it instead of sgiioc4_chipset.name.
>
> > * Remove no longer needed sgiioc4_chipset.
>
> > * Remove needless clearing of ->atapi_dma from ide_dma_sgiioc4().
>
> > *
On Friday 13 July 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> > * Fix cs5535_tuneproc() to pass PIO transfer mode value instead of PIO mode
> > number to cs5535_set_speed() (fixes random PIO timings being programmed
> > and a possible OOPS). Do a little cleanup while a
On Friday 13 July 2007, Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
>
> > * Add { 0, 0 } entry to {kauai,shasta}_pio_timings[] so
> > kauai_lookup_timing()
> > always returns a valid PIO timing (fixes PIO timing not being set for
> > devices
> > with minimum PIO cyc
On Friday 13 July 2007, Sergei Shtylyov wrote:
> Bartlomiej Zolnierkiewicz wrote:
>
> > * Use ide_tune_dma() in amd74xx/via82cxxx driver, this fixes following bugs:
> > - DMA capability bit not being checked on the device
> > - DMA blacklist not being checked
> > - DMA mode being programmed
On Thursday 12 July 2007, Sergei Shtylyov wrote:
> Hello.
>
> Bartlomiej Zolnierkiewicz wrote:
>
> >>Moreover, I think the patch is quite broken. If an invalid DMA mode
> >>is passed, currently the driver sets the cycle time to 480ns (stored
> >>in drive_data) since both cycle_time and use_dma_i
* Rename it8213_tuneproc() to it8213_tune_pio() and add it8213_tuneproc()
wrapper. Move finding of the best PIO mode to the new wrapper.
* Add setting of transfer mode on the device to it8213_tuneproc().
* Don't call it8213_dma_2_pio() for PIO modes in it8213_tune_chipset().
* Use it8213_tun
* Don't call {piix,slc90e66}_dma_2_pio() for PIO modes in
{piix,slc90e66}_tune_chipset().
* Add PIO1 handling to {piix,slc90e66}_tune_chipset().
* Bump driver version.
v2:
* Remove PIO modes from {piix,slc90e66}_dma_2_pio(), they are no longer needed
there (Noticed by Sergei)
Signed-off-
ide_config_drive_speed() called by sc1200_set_xfer_mode() already gives
a meaningful warning message in case of failure.
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/sc1200.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: b/drivers/ide/pci
* Remember to select PIO data transfer (with IORDY monitored) in sil_tune_pio()
(->set_pio_mode method) so the controller is always programmed correctly for
PIO transfers (this is important if DMA is not going to be used).
* Don't set DMA/UDMA timings for PIO modes in siimage_tune_chipset().
There is no need to do it in cs5520_tune_chipset() (->speedproc method)
since it is correctly handled by cs5520_dma_on() (->ide_dma_on method).
Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
---
drivers/ide/pci/cs5520.c | 13 -
1 file changed, 4 insertions(+), 9 delet
Hi,
On Tuesday 10 July 2007, Thomas Backlund wrote:
> Alan Cox skrev:
> >> If you modprobe only sis5513
> >> OR
> >> If you modprobe only sis5513 and then sata_sis/pata_sis:
> >> - you get this:
> >> (the hdb drive does not get detected/usable)
> >
> > Don't mix old and new IDE like that
Hi,
On Friday 13 July 2007, Craig Block wrote:
> > >>Craig Block wrote:
> > >>
> > >>I'm having a problem with the 80-wire/40-wire cable detection
>
> > Jeff Garzik wrote:
> > >
> > >If you signal a 40-wire cable too fast, you get trouble with a
> > >capital T.
>
> Thanks everyone for graciousl
On Fri, Jul 13, 2007 at 11:02:03PM +0200, Bartlomiej Zolnierkiewicz wrote:
> wee, take 3
I'm probably going to drop this driver as soon as the PATA people get
their finger(s) out and respond to the issues I raised when merging
the pata_icside driver.
> v3:
> * Remove no longer needed initiali
On Friday 13 July 2007, Russell King wrote:
> On Fri, Jul 13, 2007 at 11:02:03PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > wee, take 3
>
> I'm probably going to drop this driver as soon as the PATA people get
> their finger(s) out and respond to the issues I raised when merging
> the pata_ic
On Fri, 13 Jul 2007 22:39:48 +0100
Russell King <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 13, 2007 at 11:02:03PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > wee, take 3
>
> I'm probably going to drop this driver as soon as the PATA people get
> their finger(s) out and respond to the issues I r
On Sat, Jul 14, 2007 at 12:15:23AM +0100, Alan Cox wrote:
> On Fri, 13 Jul 2007 22:39:48 +0100
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Jul 13, 2007 at 11:02:03PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > > wee, take 3
> >
> > I'm probably going to drop this driver as soon as
Tejun Heo wrote:
Only problem I've noticed is that smartctl on drives connected to sata_nv
needs '-T permissive', while if same drive is connected to sata_sil24's PMP,
it works without problem.
Error SMART Status command failed
Please get assistance from http://smartmontools.sourceforge.net/
> We need to set the IRQ enable initially so that the identity information
> can be read and the drive accessed etc. However, if no drives are
> detected on a port, there is no callback into the low level driver -
> the port_disable method is never called. (I believe it is with SATA.)
No. It act
I'm also experiencing this problem on a with the sata_nv module. I suspect
that it may at least not be controller dependant, as it's also occurring on
my silicon image controller (sata_sil, SiI3512). It looks like something
is zeroing out part of the return registers for the overall smart stat
Here's the section with the modifications you requested:
[2.212000] sata_sil :01:08.0: version 2.2
[2.216000] ACPI: PCI Interrupt Link [APC3] enabled at IRQ 18
[2.216000] ACPI: PCI Interrupt :01:08.0[A] -> Link [APC3] -> GSI 18
(level, low) -> IRQ 16
[2.216000] PCI: Setti
Ryan Power wrote:
Here's the section with the modifications you requested:
..
The same section with "if (err_mask && id[2] != 0x738c)" in place of the
previous modification:
[2.216000] scsi0 : sata_sil
[2.216000] scsi1 : sata_sil
[2.216000] ata1: SATA max UDMA/100 cmd 0xf880c080 ct
Ryan Power wrote:
> I'm also experiencing this problem on a with the sata_nv module. I
> suspect that it may at least not be controller dependant, as it's also
> occurring on my silicon image controller (sata_sil, SiI3512). It looks
> like something is zeroing out part of the return registers for
Daniel Filipiuk wrote:
> Hello, I have a doubt... I have Debian 4.0 and the kernel 2.6.22
> compiled by me, and now when I shutdown my machine, appears a message
> telling that the devices (/dev/sda5 , 6 and so on..) are busy and
> cannot be unmounted, and tells me that I must update my shutdown
>
Chuck Ebbert wrote:
> I see this on boot with kernels 2.6.22.1 and 2.6.20.15:
>
> ata1: D2H reg with I during NCQ, this message won't be printed again
>
> But I can't find anything that tells me what it means, or whether
> it's a real problem.
That's your firmware transmitting unnecessary D
63 matches
Mail list logo
