Re: [RFC] libata debugging

2005-08-28 Thread Borislav Petkov
HI Jeff, another question: unsigned int ata_dev_classify(struct ata_taskfile *tf) in drivers/scsi/libata-core.c doesn't have access to an ata_port struct and it thus cannot be converted to the new ata_msg_xxx usage. However, this function has only two users which both have ata_port defined

pdc202xx_old and CONFIG_PDC202XX_FORCE

2005-08-28 Thread Guillaume Betous
Hi all ! First, I hope to be in the right mailing-list. Please, tell me if I'm wrong. I had some minor problems to find my hard drives on the PDC20267 of my mother board (Intel SBC2). All the drives were hidden by the BIOS. I just took a look at the module code and the Kconfig file, and

TX4000 RAID and sata_promise

2005-08-28 Thread Yuri Kirsanov
Good day. I've tried latest kernel 2.6.13-rc7, TX4000 support seems to be in sata_promise already. After startup I see following in dmesg: libata version 1.12 loaded. sata_promise version 1.02 PCI: Found IRQ 5 for device :01:09.0 ata1: PATA max UDMA/133 cmd 0xCC81C200 ctl 0xCC81C238 bmdma 0x0

TX4000 RAID and sata_promise

2005-08-28 Thread Yuri Kirsanov
Look's like I've found solution. I've checked libata_core.c and found following strings in it (line 1427): if (sata_dev_present(ap)) ata_port_probe(ap); else { sstatus = scr_read(ap, SCR_STATUS); printk(KERN_INFO ata%u: no device found (phy stat

TX4000 RAID and sata_promise

2005-08-28 Thread Yuri Kirsanov
Yes, with another hard drive, which is error-free everything works just fine, with one exception: libata version 1.11 loaded. sata_promise version 1.01 PCI: Found IRQ 5 for device :01:0a.0 ata1: SATA max UDMA/133 cmd 0xCC802200 ctl 0xCC802238 bmdma 0x0 irq 5 ata2: SATA max UDMA/133 cmd

libata: clustering on or off?

2005-08-28 Thread Jeff Garzik
The constant ATA_SHT_USE_CLUSTERING in include/linux/libata.h controls the use of SCSI layer's use_clustering feature, for a great many libata drivers. The current setup has clustering disabled, which in theory causes the block layer to do less work, at the expense of a greater number of

Re: libata: clustering on or off?

2005-08-28 Thread Arjan van de Ven
On Sun, 2005-08-28 at 05:42 -0400, Jeff Garzik wrote: The constant ATA_SHT_USE_CLUSTERING in include/linux/libata.h controls the use of SCSI layer's use_clustering feature, for a great many libata drivers. The current setup has clustering disabled, which in theory causes the block layer to

Re: libata: clustering on or off?

2005-08-28 Thread Jens Axboe
On Sun, Aug 28 2005, Arjan van de Ven wrote: On Sun, 2005-08-28 at 05:42 -0400, Jeff Garzik wrote: The constant ATA_SHT_USE_CLUSTERING in include/linux/libata.h controls the use of SCSI layer's use_clustering feature, for a great many libata drivers. The current setup has clustering

Re: libata: clustering on or off?

2005-08-28 Thread Christoph Hellwig
On Sun, Aug 28, 2005 at 04:20:19PM +0200, Jens Axboe wrote: Agree, we should just remove the ability to control clustering, as it really overlaps with the segment settings anyways. What are we going to do with iscsi then? It really doesn't like segments over a pages size. Best thing would

Re: libata: clustering on or off?

2005-08-28 Thread Jens Axboe
On Sun, Aug 28 2005, Christoph Hellwig wrote: On Sun, Aug 28, 2005 at 04:20:19PM +0200, Jens Axboe wrote: Agree, we should just remove the ability to control clustering, as it really overlaps with the segment settings anyways. What are we going to do with iscsi then? It really doesn't

[git patches] 2.6.x libata updates

2005-08-28 Thread Jeff Garzik
Please pull from the 'upstream' branch of rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git to obtain the changes described in the following diffstat/shortlog/patch. It's mostly fixes for uncommon paths (PIO, ATAPI), and new PCI IDs. Stuff not urgent enough for 2.6.13.