[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: problem with SATA disk, difference between standard kernel and Debian kernel



lee wrote:

> On Thu, Dec 11, 2008 at 10:40:50PM +0100, Emanoil Kotsev wrote:
>> 
>> do you have custom kernel or debian stock kernel.
> 
> Until today, I was using a standard kernel from kernel.org. Today I
> downloaded the package with the Debian kernel sources (2.6.24, blah
> etchnhalf or something like that ...), configured it and made a kernel
> package with "make-kpkg kernel_image -us -uc", installed the package I
> made, and now I'm using that kernel.

OK, it's not the newest one but still better as 2.6.18 - let's hope it will
solve your problems

> 
> I'm not sure if I could use a pre-built Debian kernel: the installer
> couldn't access the SATA disks because it didn't have the module for
> the controller, and a pre-built standard Debian kernel might not have
> that, either.

The installer uses different kernel, though. I would recommend recompiling
kernel, only if you are missing something from the standard one. But may be
this is the case for you.

> 
>> What is standard? Please, look that you _don't_ use the ide_generic
>> or ata_generic drivers. so kernel config and lsmod check is worth I
>> think. This we have discussed in other postings. if compiling your
>> own kernel this could be the issue.  I would also see what hdparm
>> -tT says
> 
> I'll attach the .config to this mail. The ide_generic and ata_generic
> drivers do not work for this board. For the IDE disk, I'm using
> CONFIG_BLK_DEV_JMICRON: JMicron JMB36x support. The help for that says
> "Basic support for the JMicron ATA controllers. For full support use
> the libata drivers." But libata is deprecated? And I think I tried
> that, and it didn't work.
> 
> For sata, it's CONFIG_SATA_AHCI ... Hm, I don't know about
> CONFIG_ATA_PIIX:
> 
> "This option enables support for ICH5/6/7/8 Serial ATA and support for
> PATA on the Intel ESB/ICH/PIIX3/PIIX4 series host controllers."

Well, this was just an example. It is an older chipset

> 
> lspci says ICH9: "SATA controller: Intel Corporation 82801IB (ICH9) 4
> port SATA AHCI Controller (rev 02)".
> 
> Should I try CONFIG_ATA_PIIX instead (dunno if it works)?

this sounds good

> 
> 
> # hdparm -tT /dev/sdb
> 
> /dev/sdb:
>  Timing cached reads:   14464 MB in  2.00 seconds = 7241.58 MB/sec
>  Timing buffered disk reads:  202 MB in  3.02 seconds =  66.83 MB/sec
> 
> hdpparm -tT /dev/sda
> 
> /dev/sda:
>  Timing cached reads:   14308 MB in  2.00 seconds = 7164.25 MB/sec
>  Timing buffered disk reads:  208 MB in  3.02 seconds =  68.83 MB/sec
> 

this sounds also very good

> 
> That's about the same as what I see in /proc/mdstat during a rebuild:
> about 70MB/sec for the partitions at the beginning of the disk, about
> 65MB/sec for the middle and 40MB/sec for the partition at the
> end. These disks are pretty slow. A much older, single SCSI disk is
> faster to read than the SATA RAID-1, maybe not in benchmark numbers
> but in how long it takes to load something.
> 
>> I've been trying raid over usb for the last couple of months and had
>> similar problems with sata drives and no such problems with ide in usb
>> boxes. Finally no one could explain the reason for the raid loosing the
>> drive and I attached them directly to SATA bus. So far it's working.
>> 
>> Hope this information helps
> 
> Hmm ... What error messages did you get? When the disks were connected
> via USB, wouldn't you get different messages not related to SATA?
> 

something like error on urbs (those are part of usb driver) and loosing
permanently one drive from the array. So I talked to the kernel people that
helped a bit, but this did not solve the issue.
It looks like one of the drives (mostly WesternDigital) looses power, this
is what the kernel people said and thus is being lost from the raid array.

Are your disks from same model and vendor?


regards



Reply to: