SATA_SIL

SATA_SIL

[Frans de Boer]

Dear Sir,

I know, I am not the only one to find out that we can't upgrade to a
newer kernel when using SUSE 10.3. It seems that in 2.6.23 the sil
modules have been updated (newer versions) and thus render the current
system mostly unuseable. I noticed that in the sata_sil24.c source there
where a significant number of chances, which are probally not easy to
change. Overwriting the newer versions with the versions from 2.6.22.9
might work, but for how long.

Is this a problem SUSE introduced, you forgot to take legacy into
account or is it a "feature".
Is this problem adjusted in 2.6.24-rc1?

Kind regards,
Frans de Boer.

Re: SATA_SIL

[Alan Cox]

> Is this a problem SUSE introduced, you forgot to take legacy into
> account or is it a "feature".
> Is this problem adjusted in 2.6.24-rc1?

You don't provide enough information to guess.

If you are using the OpenSuSE kernel then please report this to SuSE
first (and include an lspci -vvxxx from a working run, dmesg and if
possible the relevant ata messages from the new kernel). I don't know if
the SuSE driver is the base one but if it is then they may have ideas and
if not point you back here.

If its a kernel built from the kernel.org sources then do the same but
put it in bugzilla.kernel.org and/or send the relevant bits to the
mailing list.

A useful tip if you can't get the messages on the failing case is to open
a bugzilla report and use the attach file option to attach a digital
camera photo of the screen when it fails. (Please don't email photos to
the list)

Alan

Re: SATA_SIL

[Greg Freemyer]

On 10/30/07, Frans de Boer <frans@fransdb.nl> wrote:
> Dear Sir,
>
> I know, I am not the only one to find out that we can't upgrade to a
> newer kernel when using SUSE 10.3. It seems that in 2.6.23 the sil
> modules have been updated (newer versions) and thus render the current
> system mostly unuseable. I noticed that in the sata_sil24.c source there
> where a significant number of chances, which are probally not easy to
> change. Overwriting the newer versions with the versions from 2.6.22.9
> might work, but for how long.
>
> Is this a problem SUSE introduced, you forgot to take legacy into
> account or is it a "feature".
> Is this problem adjusted in 2.6.24-rc1?
>
> Kind regards,
> Frans de Boer.

Did you try a SUSE factory kernel or a kotd (kernel of the day,
2.6.23.1 based currently)

You can find the kotd kernels on thier mirrors.

ie. ftp://suse.mirrors.tds.net/pub/projects/kernel/kotd/HEAD is in the US.

I don't know if they have released 2.6.23 factory kernels yet.

Greg
-- 
Greg Freemyer
Litigation Triage Solutions Specialist
http://www.linkedin.com/in/gregfreemyer

The Norcross Group
The Intersection of Evidence & Technology
http://www.norcrossgroup.com

Re: SATA_SIL

[Tejun Heo]

Frans de Boer wrote:
> Dear Sir,
> 
> I know, I am not the only one to find out that we can't upgrade to a
> newer kernel when using SUSE 10.3. It seems that in 2.6.23 the sil
> modules have been updated (newer versions) and thus render the current
> system mostly unuseable. I noticed that in the sata_sil24.c source there
> where a significant number of chances, which are probally not easy to
> change. Overwriting the newer versions with the versions from 2.6.22.9
> might work, but for how long.

Those are backported PMP changes and the code base very similar to
2.6.24-rc1.

> Is this a problem SUSE introduced, you forgot to take legacy into
> account or is it a "feature".
> Is this problem adjusted in 2.6.24-rc1?

Please file a bug report at bugzilla.novell.com, attach
/var/log/boot.msg and the result of "hwinfo --all" and assign it to
teheo@novell.com.

Thanks.

-- 
tejun

Re: SATA_SIL

[Tejun Heo]

[restoring linux-ide, please don't drop cc]

Frans de Boer wrote:
> Hello sir,
> 
> I just checked: the SuSE 2.6.22.9-0.4 source for sata_sil.c (among
> others) is NOT the same as the stock 2.6.22.9. Looking at your reply, I
> quess that I have to skip 2.6.23 and use the next 2.6.24 release?

Is it sata_sil or sata_sil24?  You were talking about sil24 in the
original message.

> On a more modern system, - without the sil chips - SuSE 10.3 with the
> newer 2.6.23.1 kernel is working just fine.
> 
> Do you  still like to recieve my report as suggested by you?

Yeah, it should just work.  Thanks.

-- 
tejun

Re: SATA_SIL

[Frans de Boer]

Both sil and sil24 are not the same compared to the stock 2.6.22.9
kernel.

On Fri, 2007-11-02 at 10:11 +0900, Tejun Heo wrote:
> [restoring linux-ide, please don't drop cc]
> 
> Frans de Boer wrote:
> > Hello sir,
> > 
> > I just checked: the SuSE 2.6.22.9-0.4 source for sata_sil.c (among
> > others) is NOT the same as the stock 2.6.22.9. Looking at your reply, I
> > quess that I have to skip 2.6.23 and use the next 2.6.24 release?
> 
> Is it sata_sil or sata_sil24?  You were talking about sil24 in the
> original message.
> 
> > On a more modern system, - without the sil chips - SuSE 10.3 with the
> > newer 2.6.23.1 kernel is working just fine.
> > 
> > Do you  still like to recieve my report as suggested by you?
> 
> Yeah, it should just work.  Thanks.
> 
Uh, your reacte on which part? The part of just wait for the 2.6.24
release or that you recieve the boot.msg and hwinfo output?

KR,
Frans.

Re: SATA_SIL

[Tejun Heo]

Frans de Boer wrote:
> Both sil and sil24 are not the same compared to the stock 2.6.22.9
> kernel.

And you're seeing problem on which?

>>> Do you  still like to recieve my report as suggested by you?
>> Yeah, it should just work.  Thanks.
>>
> Uh, your reacte on which part? The part of just wait for the 2.6.24
> release or that you recieve the boot.msg and hwinfo output?

It was... Yes, please report the bug && those drives should just work.

Thanks.

-- 
tejun

sata_sil

[Harold Lee]

Hi,

I just got a Cardbus / PCMCIA SATA controller using the Silicon Image 
3512 chipset. It is not working with my external SATA enclosure housing 
a WD 250 GB Caviar drive. The first error I see in dmesg is about the 
cache line size not being set. I tried unloading the sata_sil and libata 
modules, then "sudo setpci -s 03:00.0 CACHE_LINE_SIZE=08" then reloading 
them - but I still can't see the drive and I still get the "PIO error" / 
"failed to IDENTIFY (I/O error)" errors below in the dmesg output.

Any ideas?

 From lspci -v :

03:00.0 Mass storage controller: Silicon Image, Inc. SiI 3512 
[SATALink/SATARaid] Serial ATA Controller (rev 01)
        Subsystem: Silicon Image, Inc. SiI 3512 SATALink Controller
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
        I/O ports at 4010 [size=8]
        I/O ports at 4020 [size=4]
        I/O ports at 4018 [size=8]
        I/O ports at 4024 [size=4]
        I/O ports at 4000 [size=16]
        Memory at 50800000 (32-bit, non-prefetchable) [size=512]
        Expansion ROM at 50400000 [disabled] [size=512K]
        Capabilities: [60] Power Management version 2


 From dmesg:

libata version 1.20 loaded.
sata_sil 0000:03:00.0: version 0.9
PCI: Enabling device 0000:03:00.0 (0000 -> 0003)
ACPI: PCI interrupt 0000:03:00.0[A] -> GSI 11 (level, low) -> IRQ 11
sata_sil 0000:03:00.0: cache line size not set.  Driver may not function
sata_sil 0000:03:00.0: Applying R_ERR on DMA activate FIS errata fix
PCI: Setting latency timer of device 0000:03:00.0 to 64
ata1: SATA max UDMA/100 cmd 0xF8E48080 ctl 0xF8E4808A bmdma 0xF8E48000 
irq 11
ata2: SATA max UDMA/100 cmd 0xF8E480C0 ctl 0xF8E480CA bmdma 0xF8E48008 
irq 11
ata1: SATA link down (SStatus 0)
scsi9 : sata_sil
ata2: SATA link up 1.5 Gbps (SStatus 113)
ata2: PIO error
ata2: dev 0 failed to IDENTIFY (I/O error)
scsi10 : sata_sil