headers
Ryan Bourgeois | 1 Dec 2004 04:08
Favicon

Re: Raid Problem

It is software RAID, and therefore not handled by the SATA drivers.  for 
software RAID in Linux, use the RAID kernel drivers.  Alternatively, SIS 
may have a Linux driver available which would detect the RAID arrays 
created in the card's BIOS.

Vahid Modiri wrote:
> Dear sir,
> After compiling 2.6.6 or higher version of kernel in
> Mandrake 10 and considering the SATA_SIS module (for
> SIS180 raid controller) on it , I could not find the
> related striped disk device (Raid 0) after loading the
> module on kernel.
> After modprobing the SATA_SIS , an empty /dev/SCSI
> directory is created.
> Is there any point I didn't consider , or how can I
> find the raid device?
> Any help would be appreciated
> Yours
> Vahid Modiri
> Member of Technical support or IRIB
> 
> 
> 	
> 		
> __________________________________ 
> Do you Yahoo!? 
> Yahoo! Mail - You care about security. So do we. 
> http://promotions.yahoo.com/new_mail
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ide" in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 2 Dec 2004 07:36
Picon
Favicon

[BK PATCHES] 2.6.x libata minor fixes


Please do a

	bk pull bk://gkernel.bkbits.net/libata-2.6

This will update the following files:

 Documentation/DocBook/libata.tmpl |  192 +++++++++++++++++++++++++++++++++++++-
 drivers/scsi/ahci.c               |    5 
 drivers/scsi/libata-core.c        |   10 +
 drivers/scsi/libata-scsi.c        |    4 
 4 files changed, 201 insertions(+), 10 deletions(-)

through these ChangeSets:

<jgarzik <at> pobox.com> (04/11/17 1.2147.1.122)
   [libata docs] add chapter on libata driver API

<jgarzik <at> pobox.com> (04/11/16 1.2147.2.2)
   [libata ahci] minor fixes

   Add support for ioctl handling.
   Remove incorrect comment.

<jgarzik <at> pobox.com> (04/11/15 1.2147.2.1)
   [libata] fix DocBook bugs

diff -Nru a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl
--- a/Documentation/DocBook/libata.tmpl	2004-12-02 01:33:06 -05:00
+++ b/Documentation/DocBook/libata.tmpl	2004-12-02 01:33:06 -05:00
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 2 Dec 2004 08:00
Picon
Favicon

Re: page fault scalability patch V12 [0/7]: Overview and performance tests

Andrew Morton wrote:
> We need an -rc3 yet.  And I need to do another pass through the
> regressions-since-2.6.9 list.  We've made pretty good progress there
> recently.  Mid to late December is looking like the 2.6.10 date.

another for that list, BTW:

I am currently chasing a 2.6.8->2.6.9 SATA regression, which causes 
ata_piix (Intel ICH5/6/7) to not-find some SATA devices on x86-64 SMP, 
but works on UP.  Potentially related to >=4GB of RAM.

Details, in case anyone is interested:
Unless my code is screwed up (certainly possible), PIO data-in [using 
the insw() call] seems to return all zeroes on a true-blue SMP machine, 
for the identify-device command.  When this happens, libata (correctly) 
detects a bad id page and bails.  (problem doesn't show up on single CPU 
w/ HT)

What changed from 2.6.8 to 2.6.9 is

2.6.8:
	bitbang ATA taskfile registers (loads command)
	bitbang ATA data register (read id page)

2.6.9:
	bitbang ATA taskfile registers
	queue_work()
	workqueue thread bitbangs ATA data register (read id page)

So I wonder if <something> doesn't like CPU 0 sending I/O traffic to the
(Continue reading)

Permalink | Reply | 10 comments |
headers
Benjamin Herrenschmidt | 2 Dec 2004 08:05

Re: page fault scalability patch V12 [0/7]: Overview and performance tests

On Thu, 2004-12-02 at 02:00 -0500, Jeff Garzik wrote:

> 
> 2.6.9:
> 	bitbang ATA taskfile registers
> 	queue_work()
> 	workqueue thread bitbangs ATA data register (read id page)
> 
> So I wonder if <something> doesn't like CPU 0 sending I/O traffic to the 
> on-board SATA PCI device, then immediately after that, CPU 1 sending I/O 
> traffic.
> 
> Anyway, back to debugging...  :)

They may not end up in order if they are stores (the stores to the
taskfile may be out of order vs; the loads/stores to/from the data
register) unless you have a spinlock protecting both or a full sync (on
ppc), but then, I don't know the ordering things on x86_64. This could
certainly be a problem on ppc & ppc64 too.

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 4 comments |
headers
Jeff Garzik | 2 Dec 2004 08:11
Picon
Favicon

Re: page fault scalability patch V12 [0/7]: Overview and performance tests

Benjamin Herrenschmidt wrote:
> They may not end up in order if they are stores (the stores to the
> taskfile may be out of order vs; the loads/stores to/from the data
> register) unless you have a spinlock protecting both or a full sync (on
> ppc), but then, I don't know the ordering things on x86_64. This could
> certainly be a problem on ppc & ppc64 too.

Is synchronization beyond in[bwl] needed, do you think?

This specific problem is only on Intel ICHx AFAICS, which is PIO not 
MMIO and x86-only.  I presumed insw() by its very nature already has 
synchronization, but perhaps not...

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 2 comments |
headers
Jeff Garzik | 2 Dec 2004 09:29
Picon
Favicon

libata-dev queue updated


I just updated libata-dev queue in BitKeeper, to the latest upstream kernel.

No patch yet, I'll post in a day or two.  You can generate your own
patch using Documentation/BK-usage/gcapatch script in the kernel tree.

Here's a summary of the stuff sitting in this testing queue:
* new driver ata_adma (Pacific Digital PATA and SATA)
* new hardware ULi 5281 supported in sata_uli driver
* new hardware VT6421 SATA supported in sata_via driver
* support for PATA ports on Promise SATA cards
* support for newer Promise PATA cards
* ATA passthru (read: SMART support)
* other minor stuff

BK users:

	bk pull bk://gkernel.bkbits.net/libata-dev-2.6

This will update the following files:

 Documentation/DocBook/libata.tmpl |  192 ++++++++++
 drivers/scsi/Kconfig              |   18 
 drivers/scsi/Makefile             |    2 
 drivers/scsi/ahci.c               |    5 
 drivers/scsi/ata_adma.c           |  636 ++++++++++++++++++++++++++++++++++
 drivers/scsi/libata-core.c        |   48 ++
 drivers/scsi/libata-scsi.c        |  413 ++++++++++++++++++++++
 drivers/scsi/libata.h             |    2 
 drivers/scsi/pata_pdc2027x.c      |  694 ++++++++++++++++++++++++++++++++++++++
(Continue reading)

Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 2 Dec 2004 12:16

Re: page fault scalability patch V12 [0/7]: Overview and performance tests

On Thu, 2004-12-02 at 02:11 -0500, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> > They may not end up in order if they are stores (the stores to the
> > taskfile may be out of order vs; the loads/stores to/from the data
> > register) unless you have a spinlock protecting both or a full sync (on
> > ppc), but then, I don't know the ordering things on x86_64. This could
> > certainly be a problem on ppc & ppc64 too.
> 
> 
> Is synchronization beyond in[bwl] needed, do you think?

Yes, when potentially hop'ing between CPUs, definitely.

> This specific problem is only on Intel ICHx AFAICS, which is PIO not 
> MMIO and x86-only.  I presumed insw() by its very nature already has 
> synchronization, but perhaps not...

Hrm... on "pure" x86, I would expect so at the HW level, not sure about
x86_64... but there would be definitely an issue on ppc with your
scheme. You need at least a full barrier before you trigger the
workqueue. That may not be the problem you are facing now, but it would
become one.

Ben.

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jeff Garzik | 2 Dec 2004 12:21
Picon
Favicon

Re: [PATCH] libata: Use ATAPI PIO mode for specific request buffer sizes

Albert Lee wrote:
> Hi, Jeff:
> 
>   After some testing, it seems that some PATA host adapter (ex. pdc20275) cannot 
> work reliably with specific request buffer sizes under ATAPI DMA mode.
> 
> Detailed test result:
> 4096, 2048, 1024, 512, 256: OK
> 384, 257, 255, 128, 96, 64, 32:  failed (irq lost)
> 
>   It seems multiple of 256 bytes are the safe ATAPI DMA buffer sizes to use.
> 
> Attached please find the patch against libata-dev-2.6 for your review.
> Two changes:
> 1. Use ATAPI PIO mode for ATAPI REQUEST_SENSE
> 2. Use ATAPI PIO mode for specific SCSI commands issued to ATAPI device that
>     buffer_size % 256 != 0.
> 
>   Since for most commands, buffer_size % 256 is 0,  this patch
> won't introduce big impact to the performance of libata (hopefully).
>   
>   Tested OK on on my machine with pdc20275 and ASUS CD-RW drive.

hmmmmmmm.

Your change #1 makes perfect sense, and I agree it is the safer (and 
more simple) route.

I must ponder change #2 some more (after some sleep :)).  In particular, 
I am concerned that making change #2 across all controllers will hurt
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jeff Garzik | 2 Dec 2004 12:29
Picon
Favicon

Re: sata_sil performance

Rob Hughes wrote:
> Jeff,
> 
> I can understand why you did what you did looking through the code, but
> my drive, a Seagate ST3120026AS, does not need this fix. Further,
> performance has gone from 50-60 Mbit transfers to 14-15 Mbit transfers
> between the 2.6.8 and 2.6.9 kernels. And as a side not, hdparm is
> reporting "HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device"
> when doing either -I or -i as of this kernel version.

multcount is for PIO transfers, don't worry about it.  If you are doing 
PIO you are already slower than 15Mbit.

> If you're already working on a patch for this, I'd be happy to test it.
> Also, it should be noted that I'm running FC3, so I'm not sure how much
> that will play into this.

Unfortunately at this time we must judge the situation as "you just 
haven't hit the problem yet".  Yeah, the performance hit sucks, but the 
kernel _must_ be conservative and err on the side of caution.

	Jeff

-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Rob Hughes | 2 Dec 2004 12:50

Re: sata_sil performance

On Thu, 2004-12-02 at 06:29 -0500, Jeff Garzik wrote:
> Rob Hughes wrote:
> > Jeff,
> > 
> > I can understand why you did what you did looking through the code, but
> > my drive, a Seagate ST3120026AS, does not need this fix. Further,
> > performance has gone from 50-60 Mbit transfers to 14-15 Mbit transfers
> > between the 2.6.8 and 2.6.9 kernels. And as a side not, hdparm is
> > reporting "HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device"
> > when doing either -I or -i as of this kernel version.
> 
> multcount is for PIO transfers, don't worry about it.  If you are doing 
> PIO you are already slower than 15Mbit.
> 

I wasn't actually clear there. hdparm  fails entirely to get any
information from the drive. That's just the error that's thrown to the
console. This worked before SATA drives were treated as SCSI devices (<
2.6.8 or thereabouts).

> 
> > If you're already working on a patch for this, I'd be happy to test it.
> > Also, it should be noted that I'm running FC3, so I'm not sure how much
> > that will play into this.
> 
> Unfortunately at this time we must judge the situation as "you just 
> haven't hit the problem yet".  Yeah, the performance hit sucks, but the 
> kernel _must_ be conservative and err on the side of caution.

I will, of course, bow to your judgment, but I've done my own patch to
(Continue reading)

Permalink | Reply | 0 comments |

Gmane