gigabyte iRam not seen by linux

gigabyte iRam not seen by linux

[Jure Pečar]

Hi all,

I just got a gigabyte solid state disk on a test. However, it is not seen by linux. The problem is described well here:
http://www.linuxquestions.org/questions/showthread.php?t=411600

What can one do when there *is* something on the sata port but the driver doesn't recognize it? It's not even in the /sys/block/ or /sys/bus/scsi/ ...  If I don't have the device, I can't use sg utils to ask it how it feels ... 

I'd really want to use this ssd under linux, but I don't know how to debug the problem from here.


-- 

Jure Pečar
http://jure.pecar.org/

Re: gigabyte iRam not seen by linux

[Tejun Heo]

Jure Pečar wrote:
> Hi all,
> 
> I just got a gigabyte solid state disk on a test. However, it is not seen by linux. The problem is described well here:
> http://www.linuxquestions.org/questions/showthread.php?t=411600
> 
> What can one do when there *is* something on the sata port but the driver doesn't recognize it? It's not even in the /sys/block/ or /sys/bus/scsi/ ...  If I don't have the device, I can't use sg utils to ask it how it feels ... 
> 
> I'd really want to use this ssd under linux, but I don't know how to debug the problem from here.
> 

Please set up either a vanialla kernel (preferably the latestet one, 
2.6.16-rc5) or, if you can use git, #upstream branch of libata-dev 
repository. Before compiling the kernel, change #undef ATA_DEBUG in 
include/linux/libata.h to #define ATA_DEBUG. You might also need to 
increase the size of printk buffer size (kernel hacking -> kernel log 
buffer size).

After booting with such kernel, please post the result of dmesg.

Thanks.

-- 
tejun

Re: gigabyte iRam not seen by linux

[Albert Lee]

Tejun Heo wrote:
> Jure Pečar wrote:
> 
>>
>> I just got a gigabyte solid state disk on a test. However, it is not
>> seen by linux. The problem is described well here:
>> http://www.linuxquestions.org/questions/showthread.php?t=411600
>>
>> What can one do when there *is* something on the sata port but the
>> driver doesn't recognize it? It's not even in the /sys/block/ or
>> /sys/bus/scsi/ ...  If I don't have the device, I can't use sg utils
>> to ask it how it feels ...
>> I'd really want to use this ssd under linux, but I don't know how to
>> debug the problem from here.
>>
> 
> Please set up either a vanialla kernel (preferably the latestet one,
> 2.6.16-rc5) or, if you can use git, #upstream branch of libata-dev
> repository. Before compiling the kernel, change #undef ATA_DEBUG in
> include/linux/libata.h to #define ATA_DEBUG. You might also need to
> increase the size of printk buffer size (kernel hacking -> kernel log
> buffer size).
> 
> After booting with such kernel, please post the result of dmesg.
> 
> 

This pseudo SATA drive looks interesting. There is a SATA connector
on the PCI adapter. At the first glance, I thought it is a new
SATA adapter, but it is not.
(http://www6.tomshardware.com/2005/09/07/can_gigabyte/page2.html)

I am curious how it response to things like reset and IDENTIFY
DEVICE. Looking forward to Jure's dmesg.

--
Albert

Re: gigabyte iRam not seen by linux

[Jure Pečar]

> Tejun Heo wrote:
> > After booting with such kernel, please post the result of dmesg.

This is the relevant part of dmesg with 2.6.16-rc5:

SCSI subsystem initialized
libata version 1.20 loaded.
sata_nv 0000:00:0e.0: version 0.8
ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
GSI 16 sharing vector 0xB1 and IRQ 16
ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LSA0] -> GSI 23 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:0e.0 to 64
ata_device_add: ENTER
ata_host_add: ENTER
ata_port_start: prd alloc, virt ffff81007a0c1000, dma 7a0c1000
ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE482 bmdma 0xE000 irq 16
ata_host_add: ENTER
ata_port_start: prd alloc, virt ffff81007a740000, dma 7a740000
ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE082 bmdma 0xE008 irq 16
ata_device_add: probe begin
ata_device_add: ata1: probe begin
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata_bus_reset: ENTER, host 1, port 0
ata_bus_softreset: ata1: bus reset via SRST
ata_bus_reset: EXIT
ata_dev_identify: ENTER/EXIT (host 1, dev 0) -- nodev
ata_dev_identify: ENTER/EXIT (host 1, dev 1) -- nodev
ata_device_add: ata1: probe end
scsi0 : sata_nv
ata_device_add: ata2: probe begin
ata2: SATA link down (SStatus 0)
ata_device_add: ata2: probe end


On Sat, 11 Mar 2006 10:02:37 +0800
Albert Lee <albertcc@tw.ibm.com> wrote:

> 
> This pseudo SATA drive looks interesting. There is a SATA connector
> on the PCI adapter. At the first glance, I thought it is a new
> SATA adapter, but it is not.
> (http://www6.tomshardware.com/2005/09/07/can_gigabyte/page2.html)

PCI just provides the power to charge the battery. The memory controller and sata interface is implemented in the fpga. It's entirely possible that gigabyte did take some shortcuts here ... at least that's my understanding of the info above :)
But if the bios and windows see the device and know how to use it ... 

-- 

Jure Pečar
http://jure.pecar.org/

Re: gigabyte iRam not seen by linux

[Tejun Heo]

Hello, Jure.

First of all, please, don't drop To/Cc.

On Sat, Mar 11, 2006 at 03:46:30AM +0100, Jure Pe??ar wrote:
> 
> > Tejun Heo wrote:
> > > After booting with such kernel, please post the result of dmesg.
> 
> This is the relevant part of dmesg with 2.6.16-rc5:
> 
> SCSI subsystem initialized
> libata version 1.20 loaded.
> sata_nv 0000:00:0e.0: version 0.8
> ACPI: PCI Interrupt Link [LSA0] enabled at IRQ 23
> GSI 16 sharing vector 0xB1 and IRQ 16
> ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LSA0] -> GSI 23 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:0e.0 to 64
> ata_device_add: ENTER
> ata_host_add: ENTER
> ata_port_start: prd alloc, virt ffff81007a0c1000, dma 7a0c1000
> ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE482 bmdma 0xE000 irq 16
> ata_host_add: ENTER
> ata_port_start: prd alloc, virt ffff81007a740000, dma 7a740000
> ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE082 bmdma 0xE008 irq 16
> ata_device_add: probe begin
> ata_device_add: ata1: probe begin
> ata1: SATA link up 1.5 Gbps (SStatus 113)
> ata_bus_reset: ENTER, host 1, port 0
> ata_bus_softreset: ata1: bus reset via SRST
> ata_bus_reset: EXIT
> ata_dev_identify: ENTER/EXIT (host 1, dev 0) -- nodev
> ata_dev_identify: ENTER/EXIT (host 1, dev 1) -- nodev

Seems like iRam isn't reporting proper class signature.

> ata_device_add: ata1: probe end
> scsi0 : sata_nv
> ata_device_add: ata2: probe begin
> ata2: SATA link down (SStatus 0)
> ata_device_add: ata2: probe end
> 
> 
> On Sat, 11 Mar 2006 10:02:37 +0800
> Albert Lee <albertcc@tw.ibm.com> wrote:
> 
> > 
> > This pseudo SATA drive looks interesting. There is a SATA connector
> > on the PCI adapter. At the first glance, I thought it is a new
> > SATA adapter, but it is not.
> > (http://www6.tomshardware.com/2005/09/07/can_gigabyte/page2.html)
> 
> PCI just provides the power to charge the battery. The memory controller and sata interface is implemented in the fpga. It's entirely possible that gigabyte did take some shortcuts here ... at least that's my understanding of the info above :)
> But if the bios and windows see the device and know how to use it ... 

Can you apply the following patch and try again?

diff --git a/drivers/scsi/libata-core.c b/drivers/scsi/libata-core.c
index 5f1d758..c6b0a9f 100644
--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -827,7 +827,9 @@ unsigned int ata_dev_classify(const stru
 	}
 
 	DPRINTK("unknown device\n");
-	return ATA_DEV_UNKNOWN;
+	/*return ATA_DEV_UNKNOWN;*/
+	DPRINTK("XXX faking ATA_DEV_ATA\n");
+	return ATA_DEV_ATA;
 }
 
 /**
@@ -862,6 +864,10 @@ static u8 ata_dev_try_classify(struct at
 	ap->ops->tf_read(ap, &tf);
 	err = tf.feature;
 
+	DPRINTK("dev=%d, TF %02x %02x:%02x:%02x:%02x:%02x %02x %02x\n",
+		device, tf.ctl, tf.feature, tf.nsect,
+		tf.lbal, tf.lbam, tf.lbah, tf.device, tf.command);
+
 	dev->class = ATA_DEV_NONE;
 
 	/* see if device passed diags */
@@ -2134,6 +2140,8 @@ void ata_bus_reset(struct ata_port *ap)
 	if (dev1)
 		devmask |= (1 << 1);
 
+	DPRINTK("devmask=0x%x\n", devmask);
+
 	/* select device 0 again */
 	ap->ops->dev_select(ap, 0);
 

Re: gigabyte iRam not seen by linux

[Jure Pečar]

On Sat, 11 Mar 2006 12:31:43 +0900
Tejun Heo <htejun@gmail.com> wrote:

> Can you apply the following patch and try again?

OK, now we have this:

SCSI subsystem initialized
libata version 1.20 loaded.
sata_nv 0000:00:0e.0: version 0.8
ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LSA0] -> GSI 23 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:0e.0 to 64
ata_device_add: ENTER
ata_host_add: ENTER
ata_port_start: prd alloc, virt ffff810076c7e000, dma 76c7e000
ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE482 bmdma 0xE000 irq 16
ata_host_add: ENTER
ata_port_start: prd alloc, virt ffff810074551000, dma 74551000
ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE082 bmdma 0xE008 irq 16
ata_device_add: probe begin
ata_device_add: ata1: probe begin
ata1: SATA link up 1.5 Gbps (SStatus 113)
ata_bus_reset: ENTER, host 1, port 0
ata_bus_reset: devmask=0x1
ata_bus_softreset: ata1: bus reset via SRST
ata_dev_try_classify: dev=0, TF 00 00:01:01:00:00 a0 50
ata_bus_reset: EXIT
ata_dev_identify: ENTER/EXIT (host 1, dev 0) -- nodev
ata_dev_identify: ENTER/EXIT (host 1, dev 1) -- nodev
ata_device_add: ata1: probe end
scsi0 : sata_nv


-- 

Jure Pečar
http://jure.pecar.org/

Re: gigabyte iRam not seen by linux

[Tejun Heo]

Hello, again.

On Sat, Mar 11, 2006 at 09:20:13AM +0100, Jure Pe??ar wrote:
> On Sat, 11 Mar 2006 12:31:43 +0900
> Tejun Heo <htejun@gmail.com> wrote:
> 
> > Can you apply the following patch and try again?
> 
> OK, now we have this:
> 
> SCSI subsystem initialized
> libata version 1.20 loaded.
> sata_nv 0000:00:0e.0: version 0.8
> ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LSA0] -> GSI 23 (level, low) -> IRQ 16
> PCI: Setting latency timer of device 0000:00:0e.0 to 64
> ata_device_add: ENTER
> ata_host_add: ENTER
> ata_port_start: prd alloc, virt ffff810076c7e000, dma 76c7e000
> ata1: SATA max UDMA/133 cmd 0xE800 ctl 0xE482 bmdma 0xE000 irq 16
> ata_host_add: ENTER
> ata_port_start: prd alloc, virt ffff810074551000, dma 74551000
> ata2: SATA max UDMA/133 cmd 0xE400 ctl 0xE082 bmdma 0xE008 irq 16
> ata_device_add: probe begin
> ata_device_add: ata1: probe begin
> ata1: SATA link up 1.5 Gbps (SStatus 113)
> ata_bus_reset: ENTER, host 1, port 0
> ata_bus_reset: devmask=0x1
> ata_bus_softreset: ata1: bus reset via SRST
> ata_dev_try_classify: dev=0, TF 00 00:01:01:00:00 a0 50

It's reporting 0x00 for FEATURE when it should report 0x01 (indicates
diagnostic passed).

> ata_bus_reset: EXIT
> ata_dev_identify: ENTER/EXIT (host 1, dev 0) -- nodev
> ata_dev_identify: ENTER/EXIT (host 1, dev 1) -- nodev
> ata_device_add: ata1: probe end
> scsi0 : sata_nv

The patch at the tail of this mail makes ata_dev_try_classify() ignore
diagnostic code in FEATURE.  If the iRam successfully gets attached
with the patch, can you please post 'hdparm -I /dev/sdX' and 'hdparm
--Istdout /dev/sdX' of the iRam?  We're pretty curious.

Jeff, this reminds me that low level drivers which don't use
ata_dev_try_classify (ahci and sil24) currently don't check the
diagnostic codes.  Any ideas how this should be dealt with?

--- a/drivers/scsi/libata-core.c
+++ b/drivers/scsi/libata-core.c
@@ -477,7 +477,7 @@ ata_dev_try_classify(struct ata_port *ap
 	else if ((device == 0) && (err == 0x81))
 		/* do nothing */ ;
 	else
-		return ATA_DEV_NONE;
+		/*return ATA_DEV_NONE*/;
 
 	/* determine if device is ATA or ATAPI */
 	class = ata_dev_classify(&tf);

Re: gigabyte iRam not seen by linux

[Eric D. Mudama]

On 3/11/06, Tejun Heo <htejun@gmail.com> wrote:
> Hello, again.
>
> It's reporting 0x00 for FEATURE when it should report 0x01 (indicates
> diagnostic passed).

Um, do you mean the error register?  Either way, yea, it would appear
that the device is reporting that it failed its own internal
diagnostics.

Re: gigabyte iRam not seen by linux

[Tejun Heo]

Eric D. Mudama wrote:
> On 3/11/06, Tejun Heo <htejun@gmail.com> wrote:
> 
>>Hello, again.
>>
>>It's reporting 0x00 for FEATURE when it should report 0x01 (indicates
>>diagnostic passed).
> 
> 
> Um, do you mean the error register?  Either way, yea, it would appear
> that the device is reporting that it failed its own internal
> diagnostics.

Yeap, I did mean the error register. To deal with iRam, it seems that we 
just have to ignore the diagnostic code. I wonder how the diagnostic 
code would look like on ata_piix.

-- 
tejun

Re: gigabyte iRam not seen by linux

[Jure Pečar]

On Sat, 11 Mar 2006 17:58:43 +0900
Tejun Heo <htejun@gmail.com> wrote:

> The patch at the tail of this mail makes ata_dev_try_classify() ignore
> diagnostic code in FEATURE.  If the iRam successfully gets attached
> with the patch, can you please post 'hdparm -I /dev/sdX' and 'hdparm
> --Istdout /dev/sdX' of the iRam?  
> 
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -477,7 +477,7 @@ ata_dev_try_classify(struct ata_port *ap
>  	else if ((device == 0) && (err == 0x81))
>  		/* do nothing */ ;
>  	else
> -		return ATA_DEV_NONE;
> +		/*return ATA_DEV_NONE*/;
>  
>  	/* determine if device is ATA or ATAPI */
>  	class = ata_dev_classify(&tf);


That's return err; in my source ... and yes, commenting it out gives me the sda:

# cat /proc/scsi/scsi 
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: ATA      Model: GIGABYTE i-RAM   Rev: v0.9
  Type:   Direct-Access                    ANSI SCSI revision: 05

# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
	Model Number:       GIGABYTE i-RAM                          
	Serial Number:      374F93ABEF8FA122FC1C
	Firmware Revision:  v0.98   
Standards:
	Supported: 7 6 5 4 
	Likely used: 7
Configuration:
	Logical		max	current
	cylinders	8319	8319
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:    8385552
	LBA    user addressable sectors:    8386559
	device size with M = 1024*1024:        4094 MBytes
	device size with M = 1000*1000:        4293 MBytes (4 GB)
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 1
	Standby timer values: spec'd by Vendor
	R/W multiple sector transfer: Max = 16	Current = 16
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=240ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:

# hdparm --Istdout /dev/sda

/dev/sda:
 IO_support   =  0 (default 16-bit)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 522/255/63, sectors = 8386559, start = 0
045a 207f 0000 0010 0000 0000 003f 0000
0000 0000 3337 3446 3933 4142 4546 3846
4131 3232 4643 3143 0000 0000 0000 7630
2e39 3820 2020 4749 4741 4259 5445 2069
2d52 414d 2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 2020 2020 2020 8010
0000 0f00 0400 0002 0002 0007 207f 0010
003f f410 007f 0110 f7ff 007f 0000 0007
0003 0078 0078 00f0 0078 0000 0000 0000
0000 0000 0000 0000 0202 0000 0008 0000
00fc 0000 0000 4000 4000 0000 0000 4000
407f 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 1380 7510 1380 7520 1380 7530
1380 7540 1380 7550 1380 7560 1380 7570
1380 7580 0001 0000 0000 0000 01e0 01e0
01c0 01c0 01c0 01c0 01c0 01c0 7766 7777
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000

> We're pretty curious.

So am I, but probably because of different reasons:

# time tar jxf linux-2.6.16-rc5.tar.bz2 

real	0m16.662s
user	0m15.916s
sys	0m1.104s

:D

More thorough benchmarks soon.



-- 

Jure Pečar
http://jure.pecar.org/

Re: gigabyte iRam not seen by linux

[Bryan Fink]

> The patch at the tail of this mail makes ata_dev_try_classify() ignore
> diagnostic code in FEATURE.  If the iRam successfully gets attached
> with the patch, can you please post 'hdparm -I /dev/sdX' and 'hdparm
> --Istdout /dev/sdX' of the iRam?  
> 
> --- a/drivers/scsi/libata-core.c
> +++ b/drivers/scsi/libata-core.c
> @@ -477,7 +477,7 @@ ata_dev_try_classify(struct ata_port *ap
>  	else if ((device == 0) && (err == 0x81))
>  		/* do nothing */ ;
>  	else
> -		return ATA_DEV_NONE;
> +		/*return ATA_DEV_NONE*/;
>  
>  	/* determine if device is ATA or ATAPI */
>  	class = ata_dev_classify(&tf);


Hi, I'm having the same trouble with this card as everyone else. I'm 
wondering if anyone would care to comment about what the above patch may 
break.  Is it going to disable safeguards, such that if a disk in my 
system actually does crash, I won't know it?  Or, is it simply going to 
mean that I should be careful to only plug things into the system that I 
know are supported?

I'm in contact with Gigabyte, trying to get their opinion on the 
matter.  I know others have said that they are very unhelpful when it 
comes to linux support, but I'm hoping that if we can show them what's 
wrong, they could roll up a fix in a firmware release.

-Bryan