I posted a patch to the IDE list yesterday for testing which performs the
workarounds the old IDE layer does for this. I'll forward you a copy
I applied the patch, but unfortunately I get the same error messages
as before and the drive doesn't work.
Regards,
Nils
Linux version 2.6.20-rc6-mm3
On Sat, Feb 03, 2007 at 11:09:19AM +0900, Tejun Heo wrote:
(cc'ing Albert, Mark and Sergei. Hi!)
Art Haas wrote:
Hi. Sorry to say the CD-ROM is still not found. Full 'dmesg' output
listed below in hopes it provides clues.
Erggghh.. I'm sorry too. I thought I found it this time.
Hi,
I've just updated IDE quilt tree:
http://kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/
New patches:
* ide-floppy: Fix unformatted media crash
(Alan Cox [EMAIL PROTECTED])
* ide: clear bmdma status in ide_intr() for ICHx controllers (revised #4)
* ide: remove
[PATCH] ide: make ide_hwif_t.ide_dma_{host_off,off_quietly} void
* since ide_hwif_t.ide_dma_{host_off,off_quietly} always return '0'
make these functions void and while at it drop ide_ prefix
* fix comment for __ide_dma_off_quietly()
* make __ide_dma_{host_off,off_quietly,off}() void and drop
[PATCH] ide: make ide_hwif_t.ide_dma_host_on void
* since ide_hwif_t.ide_dma_host_on is called either when drive-using_dma == 1
or when return value is discarded make it void, also drop ide_ prefix
* make __ide_dma_host_on() void and drop __ prefix
v2:
* while at it rename
On 2/3/07, Nils Lavesson [EMAIL PROTECTED] wrote:
I posted a patch to the IDE list yesterday for testing which performs the
workarounds the old IDE layer does for this. I'll forward you a copy
I applied the patch, but unfortunately I get the same error messages
as before and the drive doesn't
The driver's tuneproc() method fails to set the drive's own speed -- fix this
by renaming the function to ali15x3_tune_pio() and wrapping the new tuneproc()
method around it and making it return the mode set, update the heading comment.
Also, setting PIO mode via the speedproc() method does not
So, I agree with Mark here. We should retry and fail bio-by-bio. The
end effect wouldn't be much worse than block-by-block while taking much
less time.
And perhaps flip the bio list backwards as well 8) ?
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a
Alan wrote:
So, I agree with Mark here. We should retry and fail bio-by-bio. The
end effect wouldn't be much worse than block-by-block while taking much
less time.
And perhaps flip the bio list backwards as well 8) ?
Reversing I/O lists might be the thing to do, but it gets really
complex
Yep and if the BIOS programmed the slave into DMA that might not be ideal.
How so? The bit will be programmed by set_dmamode() right after
set_piomode() is complete.
IFF we also put the device into a DMA mode. A blacklisted device would be
wrong.
See the difference? Smart one liners are
The driver's tuneproc() method fails to set the drive's own speed -- fix this
by renaming the function to cmd64x_tune_pio(), making it return the mode set,
and wrapping the new tuneproc() method around it; while at it, also get rid
of the non-working prefetch control code, remove redundant PIO5
Tejun Heo wrote:
..
Then, PACKET_IDENTIFY after configuring transfer mode fails with
-ENOENT. Meaning it saw (status (ATA_BUSY|ATA_DRQ|ATA_ERR|ATA_DF)) ==
0 in HSM_ST.
..
So, PATA gurus, can you bless us with enlightenment? :-)
Heh.. guaranteeing detection of all the strange
Hello.
Bartlomiej Zolnierkiewicz wrote:
Index: b/drivers/ide/pci/cmd64x.c
===
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -695,9 +695,10 @@ static void __devinit init_hwif_cmd64x(i
hwif-swdma_mask = 0x07;
[PATCH] ide: fix UDMA/MWDMA/SWDMA masks
* use 0x00 instead of 0x80 to disable -{ultra,mwdma,swdma}_mask
* add udma_mask field to ide_pci_device_t and use it to initialize
-ultra_mask in aec62xx, cmd64x, pdc202xx_{new,old} and piix drivers
* fix UDMA masks to match with chipset specific
Sergei Shtylyov wrote:
The driver's tuneproc() method fails to set the drive's own speed -- fix this
by renaming the function to ali15x3_tune_pio() and wrapping the new
tuneproc()
method around it and making it return the mode set, update the heading
comment.
Also, setting PIO mode via
Aaarrgghh, So sorry. I meant to reply to this subject, not the other
one. It's the sata_inic162x driver that I'm getting random results
and timeouts from.
Bob
--- Tejun Heo [EMAIL PROTECTED] wrote:
* Hardreset must not exit without actually performing reset regardless
of link status.
Hi,
Sergei Shtylyov wrote:
[Finally forgot to stamp MV's copyright on the driver, so here's take #2...]
The driver's tuneproc() method fails to set the drive's own speed -- fix this
by renaming the function to cmd64x_tune_pio(), making it return the mode set,
and wrapping the new
Alan wrote:
generic PC market, as opposed to RAID edition or MaxLine or
similar branding from other vendors, where the firmware may have been
specifically optimized for quicker command completion, quicker status
reporting and less exhaustive error recovery. Many linux users I
Is there a way
[this thread is regarding sata_inic162x, misplaced reply]
Bob Stewart wrote:
There is still something else bad going on in your driver. I've tried
everything I can think of (timing changes, flushes, and whatnot)
but I still get random timeouts and random results from md5sum
on large files.
--- Tejun Heo [EMAIL PROTECTED] wrote:
[this thread is regarding sata_inic162x, misplaced reply]
Bob Stewart wrote:
There is still something else bad going on in your driver. I've tried
everything I can think of (timing changes, flushes, and whatnot)
but I still get random timeouts and
Alan wrote:
Yep and if the BIOS programmed the slave into DMA that might not be ideal.
How so? The bit will be programmed by set_dmamode() right after
set_piomode() is complete.
IFF we also put the device into a DMA mode. A blacklisted device would be
wrong.
Hmmm... I might be
21 matches
Mail list logo
