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

Re: Notes on the QNAP-419P



Heyho!

[ for the other debian-arm people: I have installed the 419 as per 
instruction I kindly got from Martin, but couldn't boot with a RAID1 root
device. The following may be a defective disk or it may be a kernel bug, not 
sure.]

On Tuesday 01 December 2009 13:01:58 you wrote:
> Please try again with RAID.  If it doesn't work, I'll do a test
> myself.

Ok, I'm trying it now starting from an almost unmodified Debian installed as 
per your instructions (I just changed the rootpw.)


Ooops.


[ context switch ... ]


ssh, then ls /: no output. (I can Ctrl+C though)

given that the disks are brand new and the Kirkwood support in the kernel is 
also rather new: kernel bug?

uname -a
Linux syydelaervli 2.6.30-2-kirkwood #1 Sat Nov 7 00:22:58 UTC 2009 armv5tel GNU/Linux


+++
[  673.000000] ata1: Unable to stop eDMA
[  673.100000] ata1.00: exception Emask 0x52 SAct 0x1 SErr 0xffffffff action 0xe frozen
[  673.100000] ata1: SError: { RecovData RecovComm UnrecovData Persist Proto HostInt PHYRdyChg PHYInt CommWake 10B8B Dispar 
BadCRC Handshk LinkSeq TrStaTrns UnrecFIS DevExch }
[  673.100000] ata1.00: cmd 60/08:00:6e:b6:34/00:00:03:00:00/40 tag 0 ncq 4096 in
[  673.100000]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x56 (ATA bus error)
[  673.100000] ata1.00: status: { DRDY }
[  673.100000] ata1: hard resetting link
+++


Seems I don't have disk access anymore. ('ls' in ~ works, ls / doesn't.  
reboot doesn't either. So my guess is: anything that is cached is fine...)


Disks are:
[    3.800000] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)           
[    3.840000] ata1.00: ATA-8: ST3500418AS, CC37, max UDMA/133                  
[    3.840000] ata1.00: 976773168 sectors, multi 0: LBA48 NCQ (depth 31/32)     
[    3.900000] ata1.00: configured for UDMA/133                                 
[    3.900000] scsi 0:0:0:0: Direct-Access     ATA      ST3500418AS      CC37 PQ: 0 ANSI: 5                                                                     
[    6.260000] sd 0:0:0:0: [sda] 976773168 512-byte hardware sectors: (500 GB/465 GiB)                                                                          
[    6.260000] sd 0:0:0:0: [sda] Write Protect is off                           
[    6.260000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00                        
[    6.260000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA                                                          

(and the same for sdb, sdc, sdd.)

Trying to get that repeated now.

Should I try squeeze/sid/experimental kernels? [generally: is it safe to 
update to squeeze+sid on this system?  I'm likely to want to try btrfs 
soon-ish if architecture support is in standard Debian kernels.]

Unrelated:

[    1.750000] mv_xor_shared mv_xor_shared.0: Marvell shared XOR driver
[    1.750000] mv_xor_shared mv_xor_shared.1: Marvell shared XOR driver
[    1.790000] mv_xor mv_xor.0: Marvell XOR: ( xor cpy )
[    1.830000] mv_xor mv_xor.1: Marvell XOR: ( xor fill cpy )
[    1.870000] mv_xor mv_xor.2: Marvell XOR: ( xor cpy )
[    1.910000] mv_xor mv_xor.3: Marvell XOR: ( xor fill cpy )
...
[   33.900000] xor: measuring software checksum speed
[   33.950000]    arm4regs  :  1090.000 MB/sec
[   34.000000]    8regs     :   808.400 MB/sec
[   34.050000]    32regs    :   728.400 MB/sec
[   34.050000] xor: using function: arm4regs (1090.000 MB/sec)

is 'xor: using...' only indicating which software xor method is fastest, or
is md here not using hardware xor?

Just curious, the load on this system will be so light it could use xor on 
the 8051 of an old 2400 baud modem for all I care.  Or almost. ;-)

cheers
-- vbi




-- 
featured link: http://www.pool.ntp.org

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: