On Sat, 29 Dec 2007 11:49:53 -0600
James Bottomley [EMAIL PROTECTED] wrote:
All SMP tasks sent through bsg generate messages like:
sas: smp_execute_task: task to dev 500605b01450 response: 0x0 status 0x81
Three times (because the task gets retried). Firstly, don't retry
either
In article [EMAIL PROTECTED],
Giacomo Di Ciocco [EMAIL PROTECTED] wrote:
Hello subscribers,
theres any utility to query/manage controller status/features ?
I'm using this card for a Raid 10 array made of four 300GB sata disks,
on a debian sarge with kernel 2.6.19.1-grsec. It runs on a dual
On Sat, Dec 29 2007 at 3:50 +0200, thanatos [EMAIL PROTECTED] wrote:
I got a sata controller ignitio
00:11.0 SATA controller: Initio Corporation INI-1623 PCI SATA-II
Controller (rev 02) (prog-if 00 [Vendor specific])
Subsystem: Initio Corporation INI-1623 PCI SATA-II Controller
On Sun, 2007-12-30 at 19:34 +0900, FUJITA Tomonori wrote:
On Sat, 29 Dec 2007 11:49:53 -0600
James Bottomley [EMAIL PROTECTED] wrote:
All SMP tasks sent through bsg generate messages like:
sas: smp_execute_task: task to dev 500605b01450 response: 0x0 status
0x81
Three times
This is bad for two reasons:
1. If they're returned to outside applications, no-one knows what
they mean.
2. Eventually they'll clash with the ever expanding standard error
codes.
The problem error code in question is ETASK. I've replaced this by
ECOMM (communications
[1.] One line summary of the problem:
using dd on a broken hdd causes kernel NULL pointer dereference
[2.] Full description of the problem/report:
I have a broken hdd (unreadable sector). While dd-ing it into another same size
hdd,
I get kernel-level error. First time it is a NULL pointer
From the backtrace, this doesn't seem to be a scsi or ide problem.
It might be a block-layer bug, or a VM problem. I've cc'd the VM people
to see what they think.
On Mon, Dec 31, 2007 at 12:06:00AM +0100, Erno Kovacs wrote:
[1.] One line summary of the problem:
using dd on a broken hdd
7 matches
Mail list logo