Re: 40-wire cable detected when directly connected

2008-01-12 Thread Bartlomiej Zolnierkiewicz
On Saturday 12 January 2008, Bartlomiej Zolnierkiewicz wrote:

[...]

 I've re-read the whole thread and it seems that the possible solution for
 Addonics card would be to detect it by PCI Subsystem Vendor/Device IDs.

It seems I wasn't paying enough attention, Tejun already thought of this
but unfortunately Addonics didn't set custom Subsystem IDs.

 Could you send the output of 'lspci -vvv -xxx' command?

Still may be useful.

Bart
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 40-wire cable detected when directly connected

2008-01-12 Thread Tobias Müller

Hi

Bartlomiej Zolnierkiewicz schrieb:

As a workaround you can try using IDE subsystem siimage driver and pass
idex=ata66 option or modify Tejun's patch to also override device side
cable detection by replacing ATA_CBL_PATA80 with ATA_CBL_PATA40_SHORT.

I'll try this.


Could you send the output of 'lspci -vvv -xxx' command?
03:04.0 RAID bus controller: Silicon Image, Inc. PCI0680 Ultra ATA-133 
Host Controller (rev 02)
Subsystem: Silicon Image, Inc. Winic W-680 (Silicon Image 680 
based)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium 
TAbort- TAbort- MAbort- SERR- PERR- INTx-

Latency: 64, Cache Line Size: 4 bytes
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at df00 [size=8]
Region 1: I/O ports at de00 [size=4]
Region 2: I/O ports at dd00 [size=8]
Region 3: I/O ports at dc00 [size=4]
Region 4: I/O ports at db00 [size=16]
Region 5: Memory at fdcff000 (32-bit, non-prefetchable) [size=256]
[virtual] Expansion ROM at fdb0 [disabled] [size=512K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)

Status: D0 PME-Enable- DSel=0 DScale=2 PME-
Kernel driver in use: pata_sil680
00: 95 10 80 06 07 00 90 02 02 00 04 01 01 40 00 00
10: 01 df 00 00 01 de 00 00 01 dd 00 00 01 dc 00 00
20: 01 db 00 00 00 f0 cf fd 00 00 00 00 95 10 80 36
30: 00 00 00 00 60 00 00 00 00 00 00 00 0f 01 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 01 00 22 06 00 40 00 64 00 00 00 00 00 00 00 00
70: 08 00 00 00 00 60 1f 7c 08 00 00 00 00 30 1f 7c
80: 03 00 00 00 02 00 00 00 00 00 11 00 09 19 22 51
90: 00 fe 00 0d ff ff ff 3b 00 00 00 19 00 00 00 00
a0: 01 62 c1 10 c1 10 8a 32 c1 10 92 43 07 40 09 40
b0: 01 62 c1 10 c1 10 8a 32 c1 10 92 43 00 40 09 40
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Regards
  Tobias


smime.p7s
Description: S/MIME Cryptographic Signature


Re: 40-wire cable detected when directly connected

2008-01-12 Thread Tejun Heo
Tobias Müller wrote:
 Hi
 
 Please apply the attached patch and specify libata.force_cbl=80 as
 kernel boot parameter.  If you load libata from initrd or after boot you
 need to pass 'force_cbl=80' as module parameter.  How you do it depends
 on your distro.

Ah.. right.  I'm brewing more complete debug helper patch.  I'll take
the above into consideration.

-- 
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: 40-wire cable detected when directly connected

2008-01-11 Thread Tobias Müller

Tejun Heo schrieb:

I don't know very well about CF but does it even fill UDMA/33?  What
does 'dd if=/dev/sdc of=/dev/null bs=1M count=16 iflag=direct' say?  You
can increase count for more reliable result.


16+0 Datensätze ein
16+0 Datensätze aus
16777216 Bytes (17 MB) kopiert, 0,561688 s, 29,9 MB/s

And hdparm -I /dev/sdc says it should be compatible to udma5.

/dev/sdc:

ATA device, with non-removable media
Model Number:   SanDisk SDCFX4-8192
Serial Number:  010611E2297S0510
Firmware Revision:  HDX 4.20
Standards:
Supported: 4
Likely used: 4
Configuration:
Logical max current
cylinders   15880   15880
heads   16  16
sectors/track   63  63
--
CHS current addressable sectors:   16007040
LBAuser addressable sectors:   16007040
device size with M = 1024*1024:7815 MBytes
device size with M = 1000*1000:8195 MBytes (8 GB)
Capabilities:
LBA, IORDY(may be)(cannot be disabled)
Standby timer values: spec'd by Vendor
R/W multiple sector transfer: Max = 4   Current = 0
DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4
 Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
 Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
Enabled Supported:
Write cache
   *CFA feature set



smime.p7s
Description: S/MIME Cryptographic Signature


Re: 40-wire cable detected when directly connected

2008-01-10 Thread Tejun Heo
Tobias Müller wrote:
 Hello!
 
 I'm running 2.6.24-rc7 with an Addonics AD4CFPRJ Quad-CF PCI Controller 
 (http://www.addonics.com/products/flash_memory_reader/ad4cfprj.asp) using 
 Silicon Image PCI0680 chipset which is connected direct (no cables) with 2 
 Compact-Flash Cards.
 
 In configured
 CONFIG_ATA=y
 CONFIG_PATA_SIL680=y
 
 and the controller is correclty found, but it complains about 40-wire cables, 
 but I'm not using any cables
 at all.
 
 Is there a solution to disable this check or to correct this?

The usual way to correct this is to add a whitelist to override cable
detection.  Laptops can be identified using dmi data and add-on cards
hopefully with subsystem.  Dang...  Addonics didn't set Subsystem.

I don't know very well about CF but does it even fill UDMA/33?  What
does 'dd if=/dev/sdc of=/dev/null bs=1M count=16 iflag=direct' say?  You
can increase count for more reliable result.

-- 
tejun
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html