* [sata] libata update
@ 2004-03-27 2:27 Jeff Garzik
2004-03-30 22:59 ` Petr Sebor
0 siblings, 1 reply; 19+ messages in thread
From: Jeff Garzik @ 2004-03-27 2:27 UTC (permalink / raw)
To: linux-ide; +Cc: Linux Kernel
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]
More work on libata... human-readable summary:
* scsi portion of command submission path now a lot more lightweight.
Should reduce CPU usage a bit.
* improved documentation (see below)
* New SiS SATA driver.
* Promise: minor improvements in locking, error handling, and
initialization. Promise users, please test.
* Intel ICH5: minor improvements in probing and combined mode handling.
Intel users, please test.
This is going to Linus after 2.6.5 is released.
BK repositories:
http://gkernel.bkbits.net/libata-2.[46]
Patches:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.4.25-libata15.patch.bz2
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/2.6.5-rc2-bk6-libata2.patch.bz2
And also, there are some PDF docs generated from the source code.
Although this is always available via "make pdfdocs", I also post this
document at
http://www.kernel.org/pub/linux/kernel/people/jgarzik/libata/libata.pdf
I have attached the short and long changelogs for the above patches,
versus upstream 2.6.x.
[-- Attachment #2: changelog.txt --]
[-- Type: text/plain, Size: 1150 bytes --]
<uwe.koziolek:gmx.net>:
o [libata] Add driver for SiS 964/180 SATA
Jeff Garzik:
o [libata sata_promise] better locking and error handling
o [libata] more documentation
o [libata] more cmd queue path cleanups
o [libata] more command queue path cleanup
o [libata] clean up command queue/submit path a bit
o [libata sata_promise] minor initialization updates
o [libata] documentation, and a couple tiny cleanups
o [libata] use scsi host lock
o [libata] reduce diff with 2.4 libata backport
o [libata] pci_dma_error() was renamed to pci_dma_mapping_error()
o [ata] move some generic stuff linux/libata.h -> linux/ata.h
o [libata] consolidate data transfer mode handling
o [libata] set up some of the per-command data beforehand
o [libata sata_promise] check for PATA port on PDC20375
o [libata ata_piix] fix combined mode device detection
o [libata ata_piix] clean up combined mode handling
o [libata ata_piix] do not disable SATA port on module unload
o [libata] use kmap_atomic() rather than kmap()
o [libata] use new pci_dma_error() to check for pci_map_single() failure
o [libata sata_sis] minor cleanups
[-- Attachment #3: changelog-long.txt --]
[-- Type: text/plain, Size: 5886 bytes --]
ChangeSet@1.1694, 2004-03-26 20:40:58-05:00, jgarzik@redhat.com
[libata sata_promise] better locking and error handling
* Prefer spin_lock() to spin_lock_irq() in interrupt handler
* Reset each port, before probing the SATA phy
* Reset port when every time an error occurs
ChangeSet@1.1673.6.13, 2004-03-26 18:02:34-05:00, jgarzik@redhat.com
[libata] more documentation
libata-scsi.c should now be fully documented.
ChangeSet@1.1673.6.12, 2004-03-26 04:04:17-05:00, jgarzik@redhat.com
[libata] more cmd queue path cleanups
Final part in tonight's series of changes to clean up the
command queueing path.
The simulate-ATA-over-SCSI code is moved to a new function,
ata_scsi_simulate(), and ata_scsi_rw_queue() is renamed to
ata_scsi_translate(). With the SCSI CDB debugging dump function
also moved into its own function, the queue-command path is now
nice, compact, and readable.
ChangeSet@1.1673.6.11, 2004-03-26 03:32:10-05:00, jgarzik@redhat.com
[libata] more command queue path cleanup
A new helper ata_scsi_xlat_possible(), and the command queue path
gets a bit more compact.
As side effects we kill the 'cmd_size' argument from two functions,
and mark ata_scsi_rw_queue() as static, as its only needed
in libata-scsi.c.
ChangeSet@1.1673.6.10, 2004-03-26 03:20:47-05:00, jgarzik@redhat.com
[libata] clean up command queue/submit path a bit
This change is part of a series that compartmentalizes and consolidates
ATA taskfile submission.
Here, the device-location-related checks are moved out of the ->queuecommand()
hook and into an inline helper function.
ChangeSet@1.1673.6.9, 2004-03-26 01:13:20-05:00, jgarzik@redhat.com
[libata sata_promise] minor initialization updates
* remove incorrect PATA port check
* enable undocumented bit 13 in flash control register,
because the Promise driver does so.
* wait 10 ms after setting TBG mode, for the same reason.
ChangeSet@1.1673.6.8, 2004-03-25 17:23:41-05:00, jgarzik@redhat.com
[libata] documentation, and a couple tiny cleanups
Add more per-function source code documentation. Some of this stuff
is esoteric ATA crapola, and definitely needed to be documented.
Also, two tiny cleanups spotted while documenting:
* kill unused arg from internal function ata_dev_try_classify()
* kill unused return value from ata_dev_id_string()
ChangeSet@1.1673.6.7, 2004-03-25 14:40:17-05:00, jgarzik@redhat.com
[libata] use scsi host lock
In 2.4 we release io_request_lock and take our own per-host lock,
in the ->queuecommand() hook. In 2.6, the SCSI layer provides a
useful to simply use the lock we already have, via scsi_assign_lock().
ChangeSet@1.1673.6.6, 2004-03-25 14:36:59-05:00, jgarzik@redhat.com
[libata] reduce diff with 2.4 libata backport
ChangeSet@1.1673.6.5, 2004-03-25 14:36:27-05:00, jgarzik@redhat.com
[libata] pci_dma_error() was renamed to pci_dma_mapping_error()
ChangeSet@1.1643.1.215, 2004-03-25 01:57:34-05:00, jgarzik@redhat.com
[ata] move some generic stuff linux/libata.h -> linux/ata.h
struct ata_taskfile is generic, and so far its flags (ATA_TFLAG_xxx)
Also, move ATA_PROT_xxx definitions into their own enum.
ChangeSet@1.1643.1.214, 2004-03-25 01:44:08-05:00, jgarzik@redhat.com
[libata] consolidate data transfer mode handling
The various ways you can send data to/from your ATA device is
known as the ATA taskfile protocol: PIO single sector, PIO
multiple sector, DMA, DMA TCQ, DMA NCQ, ...
Prior to this change, the data direction (read/write) was encoded
implicitly into the ATA_PROT_xxx value itself. This increased
complexity in some areas, and inhibited flexibility in others.
This change separates data direction from taskfile protocol, and also
moves the data direction flag (ATA_QCFLAG_WRITE) down to a lower
level (ATA_TFLAG_WRITE).
ChangeSet@1.1643.1.213, 2004-03-25 00:53:07-05:00, jgarzik@redhat.com
[libata] set up some of the per-command data beforehand
The data transfer mode and the set of read/write commands we generate
during normal operation remains constant until we change the data
transfer mode.
This removes a series of branches in the read/write fast path,
and in general cleans up that particular spot of code.
ChangeSet@1.1643.1.212, 2004-03-24 23:50:34-05:00, jgarzik@redhat.com
[libata sata_promise] check for PATA port on PDC20375
We don't handle it yet, but this prints out a message in its presence,
permitting verification of the check and informing users why their
PATA device is not recognized.
ChangeSet@1.1643.1.211, 2004-03-23 12:35:54-05:00, jgarzik@redhat.com
[libata ata_piix] fix combined mode device detection
SATA port detection should not have assumed that a single SATA port
mapped to a single struct ata_port. Combined mode breaks this
assumption.
Change code to simply detect if one or more devices are present
on the struct ata_port, which is what we really wanted to do.
ChangeSet@1.1643.1.210, 2004-03-23 11:52:00-05:00, jgarzik@redhat.com
[libata ata_piix] clean up combined mode handling
ChangeSet@1.1643.1.209, 2004-03-23 11:14:06-05:00, jgarzik@redhat.com
[libata ata_piix] do not disable SATA port on module unload
We were disabling the SATA port, but not enabling it on module load.
So, modprobe+rmmod+modprobe would fail.
ChangeSet@1.1643.1.208, 2004-03-23 09:20:14-05:00, jgarzik@redhat.com
[libata] use kmap_atomic() rather than kmap()
ChangeSet@1.1643.1.207, 2004-03-22 23:40:01-05:00, jgarzik@redhat.com
[libata] use new pci_dma_error() to check for pci_map_single() failure
ChangeSet@1.1643.39.2, 2004-03-21 12:15:16-05:00, jgarzik@redhat.com
[libata sata_sis] minor cleanups
ChangeSet@1.1643.39.1, 2004-03-21 11:55:35-05:00, uwe.koziolek@gmx.net
[libata] Add driver for SiS 964/180 SATA.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-27 2:27 [sata] libata update Jeff Garzik
@ 2004-03-30 22:59 ` Petr Sebor
2004-03-30 23:14 ` Jeff Garzik
` (2 more replies)
0 siblings, 3 replies; 19+ messages in thread
From: Petr Sebor @ 2004-03-30 22:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]
Hi Jeff,
I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
sata drive anymore...
I am seeing this:
-------------------------------------------------------------------
libata version 1.02 loaded.
sata_via version 0.20
sata_via(0000:00:0f.0): routed to hard irq line 11
ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC802 bmdma 0xD400 irq 20
ata2: SATA max UDMA/133 cmd 0xCC00 ctl 0xD002 bmdma 0xD408 irq 20
ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
88:203f
ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
ata1: dev 0 configured for UDMA/100
scsi0 : sata_via
ata2: no device found (phy stat 00000000)
ata2: thread exiting
scsi1 : sata_via
Using anticipatory io scheduler
Vendor: ATA Model: WDC WD2500JD-00F Rev: 1.02
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
SCSI device sda: drive cache: write through
sda: sda1 sda2
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
--------------------------------------------------------------------
instead of this:
libata version 1.00 loaded.
sata_via version 0.11
ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC802 bmdma 0xD400 irq 20
ata2: SATA max UDMA/133 cmd 0xCC00 ctl 0xD002 bmdma 0xD408 irq 20
ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
88:203f
ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
ata1: dev 0 configured for UDMA/100
scsi0 : sata_via
ata2: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
88:407f
ata2: dev 0 ATA, max UDMA/133, 72303840 sectors (lba48)
ata2: dev 0 configured for UDMA/133
scsi1 : sata_via
Using anticipatory io scheduler
Vendor: ATA Model: WDC WD2500JD-00F Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: WDC WD360GD-00FN Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 05
SCSI device sda: 488397168 512-byte hdwr sectors (250059 MB)
SCSI device sda: drive cache: write through
sda: sda1 sda2
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
SCSI device sdb: 72303840 512-byte hdwr sectors (37020 MB)
SCSI device sdb: drive cache: write through
sdb: sdb1
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
Regards,
Petr
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-30 22:59 ` Petr Sebor
@ 2004-03-30 23:14 ` Jeff Garzik
2004-03-31 1:43 ` Jarno Paananen
2004-03-30 23:16 ` Jeff Garzik
2004-03-31 8:24 ` [PATCH] " Jeff Garzik
2 siblings, 1 reply; 19+ messages in thread
From: Jeff Garzik @ 2004-03-30 23:14 UTC (permalink / raw)
To: Petr Sebor; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 160 bytes --]
Petr Sebor wrote:
> Hi Jeff,
>
> I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
> sata drive anymore...
Does this patch fix it?
Jeff
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1184 bytes --]
===== drivers/scsi/sata_via.c 1.10 vs edited =====
--- 1.10/drivers/scsi/sata_via.c Thu Mar 25 07:30:08 2004
+++ edited/drivers/scsi/sata_via.c Tue Mar 30 18:13:16 2004
@@ -56,6 +56,7 @@
static int svia_init_one (struct pci_dev *pdev, const struct pci_device_id *ent);
static u32 svia_scr_read (struct ata_port *ap, unsigned int sc_reg);
static void svia_scr_write (struct ata_port *ap, unsigned int sc_reg, u32 val);
+static void svia_phy_reset(struct ata_port *ap);
static struct pci_device_id svia_pci_tbl[] = {
{ 0x1106, 0x3149, PCI_ANY_ID, PCI_ANY_ID, 0, 0, via_sata },
@@ -96,7 +97,7 @@
.check_status = ata_check_status_pio,
.exec_command = ata_exec_command_pio,
- .phy_reset = sata_phy_reset,
+ .phy_reset = svia_phy_reset,
.bmdma_start = ata_bmdma_start_pio,
.fill_sg = ata_fill_sg,
@@ -115,6 +116,13 @@
MODULE_DESCRIPTION("SCSI low-level driver for VIA SATA controllers");
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(pci, svia_pci_tbl);
+
+static void svia_phy_reset(struct ata_port *ap)
+{
+ ap->cbl = ATA_CBL_SATA;
+ ata_port_probe(ap);
+ ata_bus_reset(ap);
+}
static u32 svia_scr_read (struct ata_port *ap, unsigned int sc_reg)
{
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-30 22:59 ` Petr Sebor
2004-03-30 23:14 ` Jeff Garzik
@ 2004-03-30 23:16 ` Jeff Garzik
2004-03-30 23:26 ` Petr Sebor
2004-03-30 23:39 ` Bartlomiej Zolnierkiewicz
2004-03-31 8:24 ` [PATCH] " Jeff Garzik
2 siblings, 2 replies; 19+ messages in thread
From: Jeff Garzik @ 2004-03-30 23:16 UTC (permalink / raw)
To: Petr Sebor; +Cc: linux-kernel
Petr Sebor wrote:
> Hi Jeff,
>
> I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
> sata drive anymore...
>
> I am seeing this:
> -------------------------------------------------------------------
> libata version 1.02 loaded.
> sata_via version 0.20
> sata_via(0000:00:0f.0): routed to hard irq line 11
> ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC802 bmdma 0xD400 irq 20
> ata2: SATA max UDMA/133 cmd 0xCC00 ctl 0xD002 bmdma 0xD408 irq 20
> ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
> 88:203f
> ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
> ata1: dev 0 configured for UDMA/100
> scsi0 : sata_via
> ata2: no device found (phy stat 00000000)
> ata2: thread exiting
> scsi1 : sata_via
oh, and are both disks SATA?
Or is the 37G drive a PATA drive on a PATA->SATA adapter (a.k.a. bridge)?
Do you have any special settings like BIOS RAID turned on, that might
interfere with things?
Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-30 23:16 ` Jeff Garzik
@ 2004-03-30 23:26 ` Petr Sebor
2004-03-30 23:39 ` Bartlomiej Zolnierkiewicz
1 sibling, 0 replies; 19+ messages in thread
From: Petr Sebor @ 2004-03-30 23:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Jeff Garzik wrote:
> oh, and are both disks SATA?
Both drives are SATA
> Or is the 37G drive a PATA drive on a PATA->SATA adapter (a.k.a. bridge)?
Nope.
> Do you have any special settings like BIOS RAID turned on, that might
> interfere with things?
This thing is turned off. (at least I hope so... will check)
I'll try the patch you sent as soon as I reach the machine.
Thanks!
Best regards,
Petr
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-30 23:16 ` Jeff Garzik
2004-03-30 23:26 ` Petr Sebor
@ 2004-03-30 23:39 ` Bartlomiej Zolnierkiewicz
2004-03-30 23:47 ` Jeff Garzik
1 sibling, 1 reply; 19+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2004-03-30 23:39 UTC (permalink / raw)
To: Jeff Garzik, Petr Sebor; +Cc: linux-kernel
On Wednesday 31 of March 2004 01:16, Jeff Garzik wrote:
> Petr Sebor wrote:
> > Hi Jeff,
> >
> > I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
> > sata drive anymore...
> >
> > I am seeing this:
> > -------------------------------------------------------------------
> > libata version 1.02 loaded.
> > sata_via version 0.20
> > sata_via(0000:00:0f.0): routed to hard irq line 11
> > ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC802 bmdma 0xD400 irq 20
> > ata2: SATA max UDMA/133 cmd 0xCC00 ctl 0xD002 bmdma 0xD408 irq 20
> > ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
> > 88:203f
> > ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
> > ata1: dev 0 configured for UDMA/100
> > scsi0 : sata_via
> > ata2: no device found (phy stat 00000000)
> > ata2: thread exiting
> > scsi1 : sata_via
>
> oh, and are both disks SATA?
>
> Or is the 37G drive a PATA drive on a PATA->SATA adapter (a.k.a. bridge)?
Vendor: ATA Model: WDC WD360GD-00FN Rev: 1.00
Type: Direct-Access ANSI SCSI revision: 05
WD Raptor electronics includes PATA->SATA bridge.
Bartlomiej
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-30 23:39 ` Bartlomiej Zolnierkiewicz
@ 2004-03-30 23:47 ` Jeff Garzik
2004-03-31 0:28 ` Bartlomiej Zolnierkiewicz
0 siblings, 1 reply; 19+ messages in thread
From: Jeff Garzik @ 2004-03-30 23:47 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Petr Sebor, linux-kernel
Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 31 of March 2004 01:16, Jeff Garzik wrote:
>
>>Petr Sebor wrote:
>>
>>>Hi Jeff,
>>>
>>>I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
>>>sata drive anymore...
>>>
>>>I am seeing this:
>>>-------------------------------------------------------------------
>>>libata version 1.02 loaded.
>>>sata_via version 0.20
>>>sata_via(0000:00:0f.0): routed to hard irq line 11
>>>ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC802 bmdma 0xD400 irq 20
>>>ata2: SATA max UDMA/133 cmd 0xCC00 ctl 0xD002 bmdma 0xD408 irq 20
>>>ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
>>>88:203f
>>>ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
>>>ata1: dev 0 configured for UDMA/100
>>>scsi0 : sata_via
>>>ata2: no device found (phy stat 00000000)
>>>ata2: thread exiting
>>>scsi1 : sata_via
>>
>>oh, and are both disks SATA?
>>
>>Or is the 37G drive a PATA drive on a PATA->SATA adapter (a.k.a. bridge)?
>
>
> Vendor: ATA Model: WDC WD360GD-00FN Rev: 1.00
> Type: Direct-Access ANSI SCSI revision: 05
>
> WD Raptor electronics includes PATA->SATA bridge.
Yes, a lot of drives do.
I meant outside the drive, an adapter/bridge the user plugs into the
device, that allows it to pretend it is a SATA device.
Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-30 23:47 ` Jeff Garzik
@ 2004-03-31 0:28 ` Bartlomiej Zolnierkiewicz
2004-03-31 2:33 ` Jeff Garzik
0 siblings, 1 reply; 19+ messages in thread
From: Bartlomiej Zolnierkiewicz @ 2004-03-31 0:28 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Petr Sebor, linux-kernel
On Wednesday 31 of March 2004 01:47, Jeff Garzik wrote:
> Bartlomiej Zolnierkiewicz wrote:
> > On Wednesday 31 of March 2004 01:16, Jeff Garzik wrote:
> >>Petr Sebor wrote:
> >>>Hi Jeff,
> >>>
> >>>I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
> >>>sata drive anymore...
> >>>
> >>>I am seeing this:
> >>>-------------------------------------------------------------------
> >>>libata version 1.02 loaded.
> >>>sata_via version 0.20
> >>>sata_via(0000:00:0f.0): routed to hard irq line 11
> >>>ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC802 bmdma 0xD400 irq 20
> >>>ata2: SATA max UDMA/133 cmd 0xCC00 ctl 0xD002 bmdma 0xD408 irq 20
> >>>ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
> >>>88:203f
> >>>ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
> >>>ata1: dev 0 configured for UDMA/100
> >>>scsi0 : sata_via
> >>>ata2: no device found (phy stat 00000000)
> >>>ata2: thread exiting
> >>>scsi1 : sata_via
> >>
> >>oh, and are both disks SATA?
> >>
> >>Or is the 37G drive a PATA drive on a PATA->SATA adapter (a.k.a. bridge)?
> >
> > Vendor: ATA Model: WDC WD360GD-00FN Rev: 1.00
> > Type: Direct-Access ANSI SCSI revision: 05
> >
> > WD Raptor electronics includes PATA->SATA bridge.
>
> Yes, a lot of drives do.
>
> I meant outside the drive, an adapter/bridge the user plugs into the
> device, that allows it to pretend it is a SATA device.
Is there any difference (except cabling and power) ?
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-30 23:14 ` Jeff Garzik
@ 2004-03-31 1:43 ` Jarno Paananen
2004-03-31 1:50 ` Jeff Garzik
0 siblings, 1 reply; 19+ messages in thread
From: Jarno Paananen @ 2004-03-31 1:43 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
Jeff Garzik <jgarzik@pobox.com> writes:
> Petr Sebor wrote:
>> Hi Jeff,
>> I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
>> sata drive anymore...
>
> Does this patch fix it?
I'm using the 2.4 kernel version (would be using 2.6 if there was
support for IT8212 ide-"raid" controller, hint hint Bart :) and had
the same problem. This fixed it:
libata version 1.02 loaded.
sata_via version 0.20
sata_via(00:0f.0): routed to hard irq line 5
ata1: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 20
ata2: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 20
ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3e01
87:4003 88:407f
ata1: dev 0 ATA, max UDMA/133, 72303840 sectors (lba48)
ata1: dev 0 configured for UDMA/133
ata2: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3e01
87:4003 88:203f
ata2: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
ata2: dev 0 configured for UDMA/100
scsi1 : sata_via
scsi2 : sata_via
Vendor: ATA Model: WDC WD360GD-00FN Rev: 1.02
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: WDC WD2500JD-22F Rev: 1.02
Type: Direct-Access ANSI SCSI revision: 05
Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0
SCSI device sda: 71833096 512-byte hdwr sectors (36779 MB)
sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
SCSI device sdb: 72303840 512-byte hdwr sectors (37020 MB)
sdb: sdb1
SCSI device sdc: 488397168 512-byte hdwr sectors (250059 MB)
sdc: sdc1 < sdc5 sdc6 >
(sda is a real SCSI disk)
Thanks,
// Jarno
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-31 1:43 ` Jarno Paananen
@ 2004-03-31 1:50 ` Jeff Garzik
2004-03-31 1:53 ` Jarno Paananen
0 siblings, 1 reply; 19+ messages in thread
From: Jeff Garzik @ 2004-03-31 1:50 UTC (permalink / raw)
To: Jarno Paananen; +Cc: linux-kernel
Jarno Paananen wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
>
>
>>Petr Sebor wrote:
>>
>>>Hi Jeff,
>>>I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
>>>sata drive anymore...
>>
>>Does this patch fix it?
>
>
> I'm using the 2.4 kernel version (would be using 2.6 if there was
> support for IT8212 ide-"raid" controller, hint hint Bart :) and had
> the same problem. This fixed it:
Sorry to be dumb, but just to clear... you had the same problem, and
the patch I posted fixed it?
Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-31 1:50 ` Jeff Garzik
@ 2004-03-31 1:53 ` Jarno Paananen
0 siblings, 0 replies; 19+ messages in thread
From: Jarno Paananen @ 2004-03-31 1:53 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel
Jeff Garzik <jgarzik@pobox.com> writes:
> Jarno Paananen wrote:
>> Jeff Garzik <jgarzik@pobox.com> writes:
>>
>>>Petr Sebor wrote:
>>>
>>>>Hi Jeff,
>>>>I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
>>>>sata drive anymore...
>>>
>>>Does this patch fix it?
>> I'm using the 2.4 kernel version (would be using 2.6 if there was
>> support for IT8212 ide-"raid" controller, hint hint Bart :) and had
>> the same problem. This fixed it:
>
>
> Sorry to be dumb, but just to clear... you had the same problem, and
> the patch I posted fixed it?
Yes, exactly, sorry for the confusion.
// Jarno
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sata] libata update
2004-03-31 0:28 ` Bartlomiej Zolnierkiewicz
@ 2004-03-31 2:33 ` Jeff Garzik
0 siblings, 0 replies; 19+ messages in thread
From: Jeff Garzik @ 2004-03-31 2:33 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz; +Cc: Petr Sebor, linux-kernel
Bartlomiej Zolnierkiewicz wrote:
> On Wednesday 31 of March 2004 01:47, Jeff Garzik wrote:
>
>>Bartlomiej Zolnierkiewicz wrote:
>>
>>>On Wednesday 31 of March 2004 01:16, Jeff Garzik wrote:
>>>
>>>>Petr Sebor wrote:
>>>>
>>>>>Hi Jeff,
>>>>>
>>>>>I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
>>>>>sata drive anymore...
>>>>>
>>>>>I am seeing this:
>>>>>-------------------------------------------------------------------
>>>>>libata version 1.02 loaded.
>>>>>sata_via version 0.20
>>>>>sata_via(0000:00:0f.0): routed to hard irq line 11
>>>>>ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC802 bmdma 0xD400 irq 20
>>>>>ata2: SATA max UDMA/133 cmd 0xCC00 ctl 0xD002 bmdma 0xD408 irq 20
>>>>>ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
>>>>>88:203f
>>>>>ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
>>>>>ata1: dev 0 configured for UDMA/100
>>>>>scsi0 : sata_via
>>>>>ata2: no device found (phy stat 00000000)
>>>>>ata2: thread exiting
>>>>>scsi1 : sata_via
>>>>
>>>>oh, and are both disks SATA?
>>>>
>>>>Or is the 37G drive a PATA drive on a PATA->SATA adapter (a.k.a. bridge)?
>>>
>>> Vendor: ATA Model: WDC WD360GD-00FN Rev: 1.00
>>> Type: Direct-Access ANSI SCSI revision: 05
>>>
>>>WD Raptor electronics includes PATA->SATA bridge.
>>
>>Yes, a lot of drives do.
>>
>>I meant outside the drive, an adapter/bridge the user plugs into the
>>device, that allows it to pretend it is a SATA device.
>
>
> Is there any difference (except cabling and power) ?
Most drives use the well-known Marvell phy chip, while adapters are a
bit more random...
Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* [PATCH] Re: [sata] libata update
2004-03-30 22:59 ` Petr Sebor
2004-03-30 23:14 ` Jeff Garzik
2004-03-30 23:16 ` Jeff Garzik
@ 2004-03-31 8:24 ` Jeff Garzik
2004-03-31 11:50 ` Petr Sebor
2 siblings, 1 reply; 19+ messages in thread
From: Jeff Garzik @ 2004-03-31 8:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Petr Sebor, jpaana
[-- Attachment #1: Type: text/plain, Size: 827 bytes --]
Petr Sebor wrote:
> Hi Jeff,
>
> I have upgraded from 2.6.3 to 2.6.5-rc3 and can't see the secondary
> sata drive anymore...
>
> I am seeing this:
> -------------------------------------------------------------------
> libata version 1.02 loaded.
> sata_via version 0.20
> sata_via(0000:00:0f.0): routed to hard irq line 11
> ata1: SATA max UDMA/133 cmd 0xC400 ctl 0xC802 bmdma 0xD400 irq 20
> ata2: SATA max UDMA/133 cmd 0xCC00 ctl 0xD002 bmdma 0xD408 irq 20
> ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3c01 87:4003
> 88:203f
> ata1: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
> ata1: dev 0 configured for UDMA/100
> scsi0 : sata_via
> ata2: no device found (phy stat 00000000)
Here's a potentially better patch, if you guys (or anyone else) would be
willing to give it a quick test...?
Jeff
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1577 bytes --]
===== drivers/scsi/sata_via.c 1.10 vs edited =====
--- 1.10/drivers/scsi/sata_via.c Thu Mar 25 07:30:08 2004
+++ edited/drivers/scsi/sata_via.c Wed Mar 31 03:20:50 2004
@@ -39,9 +39,10 @@
enum {
via_sata = 0,
- SATA_CHAN_ENAB = 0x40,
- SATA_INT_GATE = 0x41,
- SATA_NATIVE_MODE = 0x42,
+ SATA_CHAN_ENAB = 0x40, /* SATA channel enable */
+ SATA_INT_GATE = 0x41, /* SATA interrupt gating */
+ SATA_NATIVE_MODE = 0x42, /* Native mode enable */
+ SATA_PATA_SHARING = 0x49, /* PATA/SATA sharing func ctrl */
PORT0 = (1 << 1),
PORT1 = (1 << 0),
@@ -51,6 +52,9 @@
INT_GATE_ALL = PORT0 | PORT1,
NATIVE_MODE_ALL = (1 << 7) | (1 << 6) | (1 << 5) | (1 << 4),
+
+ SATA_EXT_PHY = (1 << 6), /* 0==use PATA, 1==ext phy */
+ SATA_2DEV = (1 << 5), /* SATA is master/slave */
};
static int svia_init_one (struct pci_dev *pdev, const struct pci_device_id *ent);
@@ -136,13 +140,7 @@
static unsigned long svia_scr_addr(unsigned long addr, unsigned int port)
{
- if (port >= 4)
- return 0; /* invalid port */
-
- addr &= ~((1 << 7) | (1 << 6));
- addr |= ((unsigned long)port << 6);
-
- return addr;
+ return addr + (port * 128);
}
/**
@@ -175,6 +173,13 @@
if (rc)
goto err_out;
+ pci_read_config_byte(pdev, SATA_PATA_SHARING, &tmp8);
+ if ((tmp8 & (SATA_EXT_PHY | SATA_2DEV)) != SATA_EXT_PHY) {
+ printk(KERN_ERR DRV_NAME "(%s): PATA sharing not supported (0x%x)\n",
+ pci_name(pdev), (int) tmp8);
+ rc = -EIO;
+ goto err_out_regions;
+ }
for (i = 0; i < ARRAY_SIZE(svia_bar_sizes); i++)
if ((pci_resource_start(pdev, i) == 0) ||
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] Re: [sata] libata update
2004-03-31 8:24 ` [PATCH] " Jeff Garzik
@ 2004-03-31 11:50 ` Petr Sebor
2004-03-31 16:41 ` Jarno Paananen
2004-03-31 16:48 ` Jeff Garzik
0 siblings, 2 replies; 19+ messages in thread
From: Petr Sebor @ 2004-03-31 11:50 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-kernel, jpaana
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
Jeff Garzik wrote:
> Here's a potentially better patch, if you guys (or anyone else) would
> be willing to give it a quick test...?
>
> Jeff
Not good at all ...
(eye-copied from the console @ boot time)
2.6.5-rc3 + this patch:
sata_via (0000:00:0f.0): PATA sharing not supported (0x2)
via_sata: probe of (0000:00:0f.0) failed with error -5
with following panic
unable to mount root...
wrt sata_via, no more messages are written...
Regards,
Petr
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] Re: [sata] libata update
2004-03-31 11:50 ` Petr Sebor
@ 2004-03-31 16:41 ` Jarno Paananen
2004-03-31 16:48 ` Jeff Garzik
1 sibling, 0 replies; 19+ messages in thread
From: Jarno Paananen @ 2004-03-31 16:41 UTC (permalink / raw)
To: Petr Sebor; +Cc: Jeff Garzik, linux-kernel
Petr Sebor <petr@scssoft.com> writes:
> Jeff Garzik wrote:
>
>> Here's a potentially better patch, if you guys (or anyone else)
>> would be willing to give it a quick test...?
>>
>> Jeff
>
> Not good at all ...
>
> (eye-copied from the console @ boot time)
>
> 2.6.5-rc3 + this patch:
>
> sata_via (0000:00:0f.0): PATA sharing not supported (0x2)
> via_sata: probe of (0000:00:0f.0) failed with error -5
>
> with following panic
>
> unable to mount root...
>
> wrt sata_via, no more messages are written...
Yup, no good here either (still 2.4-bk kernel):
libata version 1.02 loaded.
sata_via version 0.20
sata_via(00:0f.0): PATA sharing not supported (0x82)
Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
SCSI device sda: 71833096 512-byte hdwr sectors (36779 MB)
sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
// Jarno
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] Re: [sata] libata update
2004-03-31 11:50 ` Petr Sebor
2004-03-31 16:41 ` Jarno Paananen
@ 2004-03-31 16:48 ` Jeff Garzik
2004-03-31 17:21 ` Jarno Paananen
1 sibling, 1 reply; 19+ messages in thread
From: Jeff Garzik @ 2004-03-31 16:48 UTC (permalink / raw)
To: Petr Sebor; +Cc: linux-kernel, jpaana
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
Petr Sebor wrote:
> 2.6.5-rc3 + this patch:
>
> sata_via (0000:00:0f.0): PATA sharing not supported (0x2)
> via_sata: probe of (0000:00:0f.0) failed with error -5
Thanks for testing. OK, one bug fix and here's a new patch...
Thanks for all your help in narrowing this down,
Jeff
[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 1547 bytes --]
===== drivers/scsi/sata_via.c 1.10 vs edited =====
--- 1.10/drivers/scsi/sata_via.c Thu Mar 25 07:30:08 2004
+++ edited/drivers/scsi/sata_via.c Wed Mar 31 11:47:24 2004
@@ -39,9 +39,10 @@
enum {
via_sata = 0,
- SATA_CHAN_ENAB = 0x40,
- SATA_INT_GATE = 0x41,
- SATA_NATIVE_MODE = 0x42,
+ SATA_CHAN_ENAB = 0x40, /* SATA channel enable */
+ SATA_INT_GATE = 0x41, /* SATA interrupt gating */
+ SATA_NATIVE_MODE = 0x42, /* Native mode enable */
+ SATA_PATA_SHARING = 0x49, /* PATA/SATA sharing func ctrl */
PORT0 = (1 << 1),
PORT1 = (1 << 0),
@@ -51,6 +52,9 @@
INT_GATE_ALL = PORT0 | PORT1,
NATIVE_MODE_ALL = (1 << 7) | (1 << 6) | (1 << 5) | (1 << 4),
+
+ SATA_EXT_PHY = (1 << 6), /* 0==use PATA, 1==ext phy */
+ SATA_2DEV = (1 << 5), /* SATA is master/slave */
};
static int svia_init_one (struct pci_dev *pdev, const struct pci_device_id *ent);
@@ -136,13 +140,7 @@
static unsigned long svia_scr_addr(unsigned long addr, unsigned int port)
{
- if (port >= 4)
- return 0; /* invalid port */
-
- addr &= ~((1 << 7) | (1 << 6));
- addr |= ((unsigned long)port << 6);
-
- return addr;
+ return addr + (port * 128);
}
/**
@@ -175,6 +173,13 @@
if (rc)
goto err_out;
+ pci_read_config_byte(pdev, SATA_PATA_SHARING, &tmp8);
+ if (tmp8 & SATA_2DEV) {
+ printk(KERN_ERR DRV_NAME "(%s): SATA master/slave not supported (0x%x)\n",
+ pci_name(pdev), (int) tmp8);
+ rc = -EIO;
+ goto err_out_regions;
+ }
for (i = 0; i < ARRAY_SIZE(svia_bar_sizes); i++)
if ((pci_resource_start(pdev, i) == 0) ||
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] Re: [sata] libata update
2004-03-31 16:48 ` Jeff Garzik
@ 2004-03-31 17:21 ` Jarno Paananen
2004-03-31 21:04 ` Jeff Garzik
0 siblings, 1 reply; 19+ messages in thread
From: Jarno Paananen @ 2004-03-31 17:21 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Petr Sebor, linux-kernel
Jeff Garzik <jgarzik@pobox.com> writes:
> Petr Sebor wrote:
>> 2.6.5-rc3 + this patch:
>> sata_via (0000:00:0f.0): PATA sharing not supported (0x2)
>> via_sata: probe of (0000:00:0f.0) failed with error -5
>
>
> Thanks for testing. OK, one bug fix and here's a new patch...
>
> Thanks for all your help in narrowing this down,
Thanks, that one works for me again:
libata version 1.02 loaded.
sata_via version 0.20
sata_via(00:0f.0): routed to hard irq line 5
ata1: SATA max UDMA/133 cmd 0xB400 ctl 0xB802 bmdma 0xC400 irq 20
ata2: SATA max UDMA/133 cmd 0xBC00 ctl 0xC002 bmdma 0xC408 irq 20
ata1: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3e01
87:4003 88:407f
ata1: dev 0 ATA, max UDMA/133, 72303840 sectors (lba48)
ata1: dev 0 configured for UDMA/133
ata2: dev 0 cfg 49:2f00 82:346b 83:7f21 84:4003 85:3469 86:3e01
87:4003 88:203f
ata2: dev 0 ATA, max UDMA/100, 488397168 sectors (lba48)
ata2: dev 0 configured for UDMA/100
scsi1 : sata_via
scsi2 : sata_via
Vendor: ATA Model: WDC WD360GD-00FN Rev: 1.02
Type: Direct-Access ANSI SCSI revision: 05
Vendor: ATA Model: WDC WD2500JD-22F Rev: 1.02
Type: Direct-Access ANSI SCSI revision: 05
Attached scsi disk sda at scsi0, channel 0, id 3, lun 0
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0
Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0
SCSI device sda: 71833096 512-byte hdwr sectors (36779 MB)
sda: sda1 sda2 sda3 < sda5 sda6 sda7 >
SCSI device sdb: 72303840 512-byte hdwr sectors (37020 MB)
sdb: sdb1
SCSI device sdc: 488397168 512-byte hdwr sectors (250059 MB)
sdc: sdc1 < sdc5 sdc6 >
// Jarno
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] Re: [sata] libata update
2004-03-31 17:21 ` Jarno Paananen
@ 2004-03-31 21:04 ` Jeff Garzik
2004-04-01 7:35 ` Petr Sebor
0 siblings, 1 reply; 19+ messages in thread
From: Jeff Garzik @ 2004-03-31 21:04 UTC (permalink / raw)
To: Jarno Paananen; +Cc: Petr Sebor, linux-kernel
Jarno Paananen wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
>
>
>>Petr Sebor wrote:
>>
>>>2.6.5-rc3 + this patch:
>>>sata_via (0000:00:0f.0): PATA sharing not supported (0x2)
>>>via_sata: probe of (0000:00:0f.0) failed with error -5
>>
>>
>>Thanks for testing. OK, one bug fix and here's a new patch...
>>
>>Thanks for all your help in narrowing this down,
>
>
> Thanks, that one works for me again:
cool, that's the patch I'm going with.
Jeff
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH] Re: [sata] libata update
2004-03-31 21:04 ` Jeff Garzik
@ 2004-04-01 7:35 ` Petr Sebor
0 siblings, 0 replies; 19+ messages in thread
From: Petr Sebor @ 2004-04-01 7:35 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Jarno Paananen, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 120 bytes --]
Jeff Garzik wrote:
> cool, that's the patch I'm going with.
>
> Jeff
yup, works for me as well... thanks!
Petr
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2004-04-01 7:35 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-27 2:27 [sata] libata update Jeff Garzik
2004-03-30 22:59 ` Petr Sebor
2004-03-30 23:14 ` Jeff Garzik
2004-03-31 1:43 ` Jarno Paananen
2004-03-31 1:50 ` Jeff Garzik
2004-03-31 1:53 ` Jarno Paananen
2004-03-30 23:16 ` Jeff Garzik
2004-03-30 23:26 ` Petr Sebor
2004-03-30 23:39 ` Bartlomiej Zolnierkiewicz
2004-03-30 23:47 ` Jeff Garzik
2004-03-31 0:28 ` Bartlomiej Zolnierkiewicz
2004-03-31 2:33 ` Jeff Garzik
2004-03-31 8:24 ` [PATCH] " Jeff Garzik
2004-03-31 11:50 ` Petr Sebor
2004-03-31 16:41 ` Jarno Paananen
2004-03-31 16:48 ` Jeff Garzik
2004-03-31 17:21 ` Jarno Paananen
2004-03-31 21:04 ` Jeff Garzik
2004-04-01 7:35 ` Petr Sebor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox