On 11/2/07, Jeff Garzik [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
On Thu, 25 Oct 2007 13:18:50 +0530
Amit Shah [EMAIL PROTECTED] wrote:
On 2.6.24-rc1 (AMD Opteron 1216), my sata_nv driver produces this
output on bootup:
ata2: EH in SWNCQ mode,QC:qc_active 0x1 sactive 0x1
ata2:
Hello, Jon.
Please don't top-post.
Jon Hardcastle wrote:
Looking at the logs there is seconds(as in 2~5)
literally between when the smartd kicks in on the sata
and when it decides the drive isn't capable. I can
tell you now it takes at least 10~15 seconds for the
drive to spin up.. probably
On Friday, 2 November 2007 02:32, Shaohua Li wrote:
On Thu, 2007-11-01 at 10:04 +, Alan Cox wrote:
+ max_devices = ata_link_max_devices(ap-link);
+
+ for (i = 0; i max_devices; ++i) {
+ struct ata_device *dev = ap-link.device[i];
Better to use:
ok.
Cable detection on Nvidia PATA hosts is pathetic. The current
nv_cable_detect() assumes that the native cable detection only
mistakes 80c as 40c but this isn't true. On ASUS A8N-E, cable
register almost always says 80c is attached and it also manages to
trick the drive that the cable is 80c.
The current ata_acpi_cbl_80wire() is too retricted in its
functionality. It always reads GTM itself and only returns whether
the cable is 80 wire or not. Extend it such that...
* It accepts @gtm argument instead of reading iteslf.
* Returns one of ATA_CBL_PATA40, ATA_CBL_PATA80 or
On Sat, 03 Nov 2007 00:22:24 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Cable detection on Nvidia PATA hosts is pathetic. The current
nv_cable_detect() assumes that the native cable detection only
mistakes 80c as 40c but this isn't true. On ASUS A8N-E, cable
register almost always says 80c is
Using the initial GTM value is the right thing to do because both are
trying to check firmware setting and by the time -cable_detect runs
the controller is already forced into PIO0 by reset.
As we only look at the DMA bits that doesn't matter but I agree it would
be cleaner if we were more
Tejun Heo wrote:
Add dev-acpi_init_gtm and store initial GTM values on host
initialization. If the field is valid, ATA_PFLAG_INIT_GTM_VALID flag
is set. This is to remember BIOS/firmware programmed initial timing
for later use before reset and mode configuration modify it.
Signed-off-by:
Krzysztof Oledzki wrote:
Hello,
I just tried to switch from old IDE to libata but unfortunately kernel
(2.6.22.10) hangs during boot:
does 2.6.23.1 or 2.6.24-rc1 work?
Jeff
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL
Hello,
I just tried to switch from old IDE to libata but unfortunately kernel
(2.6.22.10) hangs during boot:
ata1: PATA max UDMA/66 cmd 0x000101e8 ctl 0x000103ee bmdma 0x00012c40 irq 11
ata2: DUMMY
ata1.00: ATAPI: HL-DT-ST CD-ROM GCR-8482B, 1.00, max MWDMA2
ara1.01: ATAPI: LITE-ON LTR-62327S,
On Fri, 2 Nov 2007, Jeff Garzik wrote:
Krzysztof Oledzki wrote:
Hello,
I just tried to switch from old IDE to libata but unfortunately kernel
(2.6.22.10) hangs during boot:
does 2.6.23.1 or 2.6.24-rc1 work?
Ah, I was afraid of this question. ;) This is a quite important server and
I
On Thu, Nov 01, 2007 at 06:43:16PM +, Denys Vlasenko wrote:
We can intrduce new, ro sections or teach gcc that combining const objects
into
non-ro sections is not a crime. I wonder why it currently disallows that.
(And it does it only _somethimes_, const pointers happily go into rw
Frans de Boer wrote:
Both sil and sil24 are not the same compared to the stock 2.6.22.9
kernel.
And you're seeing problem on which?
Do you still like to recieve my report as suggested by you?
Yeah, it should just work. Thanks.
Uh, your reacte on which part? The part of just wait for the
Daniel Drake wrote:
Again, ignore me if I'm not contributing anything useful, but I'm
increasingly thinking that the SG_IO command block in question is
perfectly valid, and doing a short read of the mode page in question
(and probably others too) is in fact required before you can know its
Both sil and sil24 are not the same compared to the stock 2.6.22.9
kernel.
On Fri, 2007-11-02 at 10:11 +0900, Tejun Heo wrote:
[restoring linux-ide, please don't drop cc]
Frans de Boer wrote:
Hello sir,
I just checked: the SuSE 2.6.22.9-0.4 source for sata_sil.c (among
others) is NOT
On Fri, 2 Nov 2007 14:29:17 +0100 (CET)
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
Hello,
I just tried to switch from old IDE to libata but unfortunately kernel
(2.6.22.10) hangs during boot:
ata1: PATA max UDMA/66 cmd 0x000101e8 ctl 0x000103ee bmdma 0x00012c40 irq 11
ata2: DUMMY
Hello, Jon.
Please don't top-post.
Jon Hardcastle wrote:
Looking at the logs there is seconds(as in 2~5)
literally between when the smartd kicks in on the sata
and when it decides the drive isn't capable. I can
tell you now it takes at least 10~15 seconds for the
drive to spin up.. probably
On Fri, 2 Nov 2007 14:29:17 +0100 (CET)
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
Hello,
I just tried to switch from old IDE to libata but unfortunately kernel
(2.6.22.10) hangs during boot:
ata1: PATA max UDMA/66 cmd 0x000101e8 ctl 0x000103ee bmdma 0x00012c40 irq 11
ata2: DUMMY
On Fri, 2 Nov 2007, Alan Cox wrote:
On Fri, 2 Nov 2007 14:29:17 +0100 (CET)
Krzysztof Oledzki [EMAIL PROTECTED] wrote:
Hello,
I just tried to switch from old IDE to libata but unfortunately kernel
(2.6.22.10) hangs during boot:
ata1: PATA max UDMA/66 cmd 0x000101e8 ctl 0x000103ee bmdma
Tejun Heo wrote:
Yeap, the SG command is fine. The drive is being weird tho. The
allocation length field says 10 bytes, so it should just have
transferred 10 bytes without causing HSM violation.
Can you please apply the attached patch and report what the kernel says
after triggering the error
Hi,
On Thursday 01 November 2007, Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
Remove atapi_error_t.
While at it:
* replace 'HWIF(drive)' by 'drive-hwif'
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-floppy.c |3 +--
On Wednesday 31 October 2007, Bartlomiej Zolnierkiewicz wrote:
Remove atapi_ireason_t.
While at it:
* replace 'HWIF(drive)' by 'drive-hwif' (or just 'hwif' where possible)
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
[...]
[PATCH] ide: remove atapi_ireason_t (take 2)
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-disk.c |1 +
1 file changed, 1 insertion(+)
Index: b/drivers/ide/ide-disk.c
===
--- a/drivers/ide/ide-disk.c
+++ b/drivers/ide/ide-disk.c
@@ -274,6
Based on the earlier work by Tejun Heo.
task-data_phase == TASKFILE_MULTI_{IN,OUT} vs drive-mult_count == 0
check is needed also for ide_taskfile_ioctl() requests that don't have
IDE_TFLAG_FLAGGED taskfile flag set.
Cc: Tejun Heo [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL
Fix __ide_do_rw_disk() to use -OUTBSYNC instead of -OUTB
(needed for pmac and scc_pata host drivers).
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-disk.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Index: b/drivers/ide/ide-disk.c
* Use task-data_phase in do_rw_taskfile() to decide what to do.
* task-prehandler is only used by TASKFILE[_MULTI]_OUT so just
use pre_task_out_intr() directly and remove no longer needed
'prehandler' field from ide_task_t.
* Remove no longer needed ide_pre_handler_t type.
There should be
* Use -data_phase to set -handler in do_rw_taskfile() instead of
setting -handler in callers of ide_raw_taskfile()/do_rw_taskfile().
* Unexport task_no_data_intr() and make it static.
There should be no functionality changes caused by this patch.
Signed-off-by: Bartlomiej Zolnierkiewicz
* Add IDE_TFLAG_CUSTOM_HANDLER taskfile flag and use it for internal requests
which require custom handlers. Check the flag in do_rw_taskfile() and set
handler accordingly.
* Cleanup ide_init_{specify,restore,setmult}_cmd() and rename it to
ide_tf_set_{specify,restore,setmult}_cmd().
*
s/WAIT_CMD/WAIT_WORSTCASE/ to make the timeout the same as in do_rw_taskfile()
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-disk.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/drivers/ide/ide-disk.c
* Add ide_tf_set_cmd() helper for selecting/setting command and data phase
(note: DMA data phases are there for completness, they are not required ATM).
* Set IDE_TFLAG_WRITE taskfile flag for write requests in __ide_do_rw_disk().
* Convert __ide_do_rw_disk() to use the new ide_tf_set_cmd()
* Add IDE_TFLAG_DMA_PIO_FALLBACK taskfile flag to indicate the need
to skip loading taskfile registers in do_rw_taskfile().
* Export do_rw_taskfile().
* Convert __ide_do_rw_disk() to use do_rw_taskfile().
* Unexport ide_tf_load().
* Unexport {pre_task_out,task_in}_intr() and make it static.
Alan Cox wrote:
On Sat, 03 Nov 2007 00:20:10 +0900
Tejun Heo [EMAIL PROTECTED] wrote:
Add dev-acpi_init_gtm and store initial GTM values on host
initialization. If the field is valid, ATA_PFLAG_INIT_GTM_VALID flag
is set. This is to remember BIOS/firmware programmed initial timing
for
Jeff Garzik wrote:
Tejun Heo wrote:
Add dev-acpi_init_gtm and store initial GTM values on host
initialization. If the field is valid, ATA_PFLAG_INIT_GTM_VALID flag
is set. This is to remember BIOS/firmware programmed initial timing
for later use before reset and mode configuration modify
Alan Cox wrote:
Using the initial GTM value is the right thing to do because both are
trying to check firmware setting and by the time -cable_detect runs
the controller is already forced into PIO0 by reset.
As we only look at the DMA bits that doesn't matter but I agree it would
be cleaner
Alan Cox wrote:
Cable detection on Nvidia PATA hosts is pathetic. The current
nv_cable_detect() assumes that the native cable detection only
mistakes 80c as 40c but this isn't true. On ASUS A8N-E, cable
register almost always says 80c is attached and it also manages to
trick the drive that
On Thu, 1 Nov 2007 09:41:46 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
On Wed, Oct 31 2007, Jens Axboe wrote:
Hi,
My x60 stopped suspending about two days ago. It just freezes after
printing
Suspending console(s)
where it would normally turn everything off and the 'moon' light
GTM results do change whether you call STM or not. GTM in many cases is
implemented as reading the current configuration value from the
controller so if you configure PIO0, it will return PIO0 timings. And,
yeah, on ASUS A8N-E, if you configure PIO0, GTM answer says DMA is off.
Oh fun - ok
On Friday 02 November 2007 18:44:40 you wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=9274
[EMAIL PROTECTED] changed:
What|Removed |Added
---
- CC|
all we can use is how the BIOS configured it. I suppose BIOS does it by
issuing trial commands which I don't think adding to libata is a good idea.
The BIOS does it by asking the hardware somehow. I traced one or two
BIOSes that far. The info is there but its not documented in the
slightest so
Hello, again. Forgot one thing.
Alan Cox wrote:
all we can use is how the BIOS configured it. I suppose BIOS does it by
issuing trial commands which I don't think adding to libata is a good idea.
The BIOS does it by asking the hardware somehow. I traced one or two
BIOSes that far. The
Alan Cox wrote:
What the function answers is not actually cable type but according to
the current configuration, using this cable type won't violate BIOS
configuration kind of answer. How the caller is to use that is the
caller's responsibility.
How does the caller make use of it ? The
On Friday 02 November 2007, Alan Cox wrote:
Using the initial GTM value is the right thing to do because both are
trying to check firmware setting and by the time -cable_detect runs
the controller is already forced into PIO0 by reset.
As we only look at the DMA bits that doesn't matter
Alan Cox wrote:
all we can use is how the BIOS configured it. I suppose BIOS does it by
issuing trial commands which I don't think adding to libata is a good idea.
The BIOS does it by asking the hardware somehow. I traced one or two
BIOSes that far. The info is there but its not documented
On Saturday 03 November 2007, Bartlomiej Zolnierkiewicz wrote:
On Friday 02 November 2007, Alan Cox wrote:
Using the initial GTM value is the right thing to do because both are
trying to check firmware setting and by the time -cable_detect runs
the controller is already forced into PIO0
Alan Cox wrote:
2. UDMA mode is configured but equal to or under UDMA33. Dunno whether
it's cable or device limit but anyways you better limit it to UDMA33 too.
If it is under UDMA33 you know it isn't a cable limit
If it is UDMA 33 and the device top is UDMA 33 it might be
This
Daniel Drake wrote:
Tejun Heo wrote:
Yeap, the SG command is fine. The drive is being weird tho. The
allocation length field says 10 bytes, so it should just have
transferred 10 bytes without causing HSM violation.
Can you please apply the attached patch and report what the kernel says
Tejun,
I've been having good success using your patches from late September
with a sil3124 pcix sata controller connected to 4 drives. Ive added
another PM and 4 more drives and connected to port 2 on the card.
However on these 4 additional drives I consistently get these errors
when doing any
detection. We're basically just trying to follow what BIOS did. Maybe
we should return ATA_CBL_PATA_MAYBE_80 unconditionally and implement
MAYBE_80 = UNK.
ata_acpi_more_filter()?
We can also use UNK intelligently in the eh code to go straight from
UDMA133/100/66 to 33 (if you don't already
On Fri, Nov 02, 2007 at 04:37:08PM -0700, Kristen Carlson Accardi wrote:
Does this patch fix your problem? It seems to get hung up while disabling
DIPM, and after thinking about this a bit, I don't think we really need
to do this anyway.
Yep, this fixes suspend/resume on my X61 thinkpad.
49 matches
Mail list logo
