On Wed, 2019-02-13 at 12:19 +0100, Roger Pau Monné wrote:
> [5.717437] general protection fault: [#1] SMP PTI
> [5.722665] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.19.20 #1
> [5.728668] Hardware name: GIGABYTE GS-R12P4S/GA-7PCSL, BIOS R12 05/20/2014
> [5.735633] RIP: 0010:__
Hello,
I'm seeing the following GP on 4.19.20, same box is working fine with
4.14:
Initializing Intel(R) Boot Agent GE v1.3.76
PXE 2.1 Build 090 (WfM 2.0)
Press Ctrl+S to enter the Setup Menu
[0.00] microcode: microcode updated early to revision 0x428, date = 2014
-05-29g initial ramdisk
On Fri, Aug 24, 2018 at 06:33:29PM -0600, Jens Axboe wrote:
> On 8/24/18 6:21 PM, Jens Axboe wrote:
> > On 8/24/18 5:16 PM, Ming Lei wrote:
> >> Hi,
> >>
> >> On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
> >>> Hi,
> >>>
> >>> Was testing other things today, but ended up with this:
>
On 8/24/18 6:21 PM, Jens Axboe wrote:
> On 8/24/18 5:16 PM, Ming Lei wrote:
>> Hi,
>>
>> On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
>>> Hi,
>>>
>>> Was testing other things today, but ended up with this:
>>>
>>> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache
On 8/24/18 5:16 PM, Ming Lei wrote:
> Hi,
>
> On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
>> Hi,
>>
>> Was testing other things today, but ended up with this:
>>
>> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
>>
>> hanging. Looking closer, the reques
Hi,
On Fri, Aug 24, 2018 at 04:20:41PM -0600, Jens Axboe wrote:
> Hi,
>
> Was testing other things today, but ended up with this:
>
> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
>
> hanging. Looking closer, the request is successfully queued and the
> caller is w
On 8/24/18 4:20 PM, Jens Axboe wrote:
> Hi,
>
> Was testing other things today, but ended up with this:
>
> # echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
>
> hanging. Looking closer, the request is successfully queued and the
> caller is waiting on rq execution and
Hi,
Was testing other things today, but ended up with this:
# echo "write through" > /sys/block/sde/device/scsi_disk/4:0:0:0/cache_type
hanging. Looking closer, the request is successfully queued and the
caller is waiting on rq execution and completion, but the request is
sitting in the hctx->di
On Thu, 02 Mar 2017 11:18:23 -0800
James Bottomley wrote:
> On March 2, 2017 11:05:05 AM PST, Stephen Hemminger
> wrote:
> >On Thu, 02 Mar 2017 10:36:17 -0800
> >James Bottomley wrote:
> >
> >> On March 2, 2017 10:23:24 AM PST, Stephen Hemminger
> > wrote:
> >> >On Thu, 2 Mar 2017 14:25:
On March 2, 2017 10:23:24 AM PST, Stephen Hemminger
wrote:
>On Thu, 2 Mar 2017 14:25:14 +0100
>Hannes Reinecke wrote:
>
>> On 03/02/2017 02:40 AM, Stephen Hemminger wrote:
>> > On Thu, 2 Mar 2017 01:56:15 +0100
>> > Christoph Hellwig wrote:
>> >
>> >> On Thu, Mar 02, 2017 at 01:01:35AM +0100,
On March 2, 2017 11:05:05 AM PST, Stephen Hemminger
wrote:
>On Thu, 02 Mar 2017 10:36:17 -0800
>James Bottomley wrote:
>
>> On March 2, 2017 10:23:24 AM PST, Stephen Hemminger
> wrote:
>> >On Thu, 2 Mar 2017 14:25:14 +0100
>> >Hannes Reinecke wrote:
>> >
>> >> On 03/02/2017 02:40 AM, Stephen
On Thu, 02 Mar 2017 10:36:17 -0800
James Bottomley wrote:
> On March 2, 2017 10:23:24 AM PST, Stephen Hemminger
> wrote:
> >On Thu, 2 Mar 2017 14:25:14 +0100
> >Hannes Reinecke wrote:
> >
> >> On 03/02/2017 02:40 AM, Stephen Hemminger wrote:
> >> > On Thu, 2 Mar 2017 01:56:15 +0100
> >> >
On Thu, 2 Mar 2017 14:25:14 +0100
Hannes Reinecke wrote:
> On 03/02/2017 02:40 AM, Stephen Hemminger wrote:
> > On Thu, 2 Mar 2017 01:56:15 +0100
> > Christoph Hellwig wrote:
> >
> >> On Thu, Mar 02, 2017 at 01:01:35AM +0100, Christoph Hellwig wrote:
> >>> On Wed, Mar 01, 2017 at 07:54:12AM
On Thu, 2 Mar 2017 14:25:14 +0100
Hannes Reinecke wrote:
> On 03/02/2017 02:40 AM, Stephen Hemminger wrote:
> > On Thu, 2 Mar 2017 01:56:15 +0100
> > Christoph Hellwig wrote:
> >
> >> On Thu, Mar 02, 2017 at 01:01:35AM +0100, Christoph Hellwig wrote:
> >>> On Wed, Mar 01, 2017 at 07:54:12AM
On 03/02/2017 02:40 AM, Stephen Hemminger wrote:
On Thu, 2 Mar 2017 01:56:15 +0100
Christoph Hellwig wrote:
On Thu, Mar 02, 2017 at 01:01:35AM +0100, Christoph Hellwig wrote:
On Wed, Mar 01, 2017 at 07:54:12AM -0800, Stephen Hemminger wrote:
http://git.infradead.org/users/hch/block.
On Thu, 2 Mar 2017 01:56:15 +0100
Christoph Hellwig wrote:
> On Thu, Mar 02, 2017 at 01:01:35AM +0100, Christoph Hellwig wrote:
> > On Wed, Mar 01, 2017 at 07:54:12AM -0800, Stephen Hemminger wrote:
> > > >
> > > > http://git.infradead.org/users/hch/block.git/commitdiff/148cff67b401e22
On Thu, 2 Mar 2017 01:01:35 +0100
Christoph Hellwig wrote:
> On Wed, Mar 01, 2017 at 07:54:12AM -0800, Stephen Hemminger wrote:
> > >
> > > http://git.infradead.org/users/hch/block.git/commitdiff/148cff67b401e2229c076c0ea418712654be77e4
> > >
> >
> > It appears that is already in the code
On Thu, Mar 02, 2017 at 01:01:35AM +0100, Christoph Hellwig wrote:
> On Wed, Mar 01, 2017 at 07:54:12AM -0800, Stephen Hemminger wrote:
> > >
> > > http://git.infradead.org/users/hch/block.git/commitdiff/148cff67b401e2229c076c0ea418712654be77e4
> >
> > It appears that is already in the code I a
On Wed, 2017-03-01 at 10:57 -0800, James Bottomley wrote:
> On Wed, 2017-03-01 at 10:48 -0800, Stephen Hemminger wrote:
> > On Tue, 28 Feb 2017 22:20:58 -0800
> > James Bottomley wrote:
> >
> > > On Tue, 2017-02-28 at 17:25 -0800, Stephen Hemminger wrote:
> > > > [1.346023] hv_storvsc: IO cm
On Wed, 01 Mar 2017 15:09:44 -0800
James Bottomley wrote:
> On Wed, 2017-03-01 at 13:27 -0800, Stephen Hemminger wrote:
> > Ok here is much better data, wasn't accounting for the offset in the
> > payload
>
> But now both responses are the same:
>
> > Working 4.10
> [...]
> > [1.048920]
On Wed, 2017-03-01 at 13:27 -0800, Stephen Hemminger wrote:
> Ok here is much better data, wasn't accounting for the offset in the
> payload
But now both responses are the same:
> Working 4.10
[...]
> [1.048920] hv_storvsc: INQUIRY cmd 0x12 0x0 0x0 scsi status 0x0
> srb status 0x20 length 36
On Wed, Mar 01, 2017 at 07:54:12AM -0800, Stephen Hemminger wrote:
> >
> > http://git.infradead.org/users/hch/block.git/commitdiff/148cff67b401e2229c076c0ea418712654be77e4
>
> It appears that is already in the code I am testing in linux-next...
It's in -next now, but it wasn't at the time yo
On Wed, Mar 1, 2017 at 10:48 AM, Stephen Hemminger
wrote:
>
> Bad 4.11 initial INQUIRY buffer
> [1.218159] data: : 00 00 05 02 1f 00 00 02 4d 73 66 74 20 20 20 20
> [1.225654] data: 0010: 56 69 72 74 75 61 6c 20 44 69 73 6b 20 20 20 20
> [1.242930] data: 0020: 31 2e 30
Ok here is much better data, wasn't accounting for the offset in the payload
Working 4.10
[1.020041] scsi host0: storvsc_host_t
[1.024998] hv_storvsc: INQUIRY cmd 0x12 0x0 0x0 scsi status 0x0 srb status
0x1 length 36
[1.027452] hv_storvsc: payload size 288 count 1 offset 3072 len 36
On Wed, 01 Mar 2017 11:20:22 -0800
James Bottomley wrote:
> On Wed, 2017-03-01 at 10:57 -0800, James Bottomley wrote:
> > On Wed, 2017-03-01 at 10:48 -0800, Stephen Hemminger wrote:
> > > On Tue, 28 Feb 2017 22:20:58 -0800
> > > James Bottomley wrote:
> > >
> > > > On Tue, 2017-02-28 at 17:
On Wed, 2017-03-01 at 10:48 -0800, Stephen Hemminger wrote:
> On Tue, 28 Feb 2017 22:20:58 -0800
> James Bottomley wrote:
>
> > On Tue, 2017-02-28 at 17:25 -0800, Stephen Hemminger wrote:
> > > [1.346023] hv_storvsc: IO cmd 0x12 0x0 0x0 scsi status 0x0
> > > srb
> > > status 0x20 length 36
>
On Tue, 28 Feb 2017 22:20:58 -0800
James Bottomley wrote:
> On Tue, 2017-02-28 at 17:25 -0800, Stephen Hemminger wrote:
> > [1.346023] hv_storvsc: IO cmd 0x12 0x0 0x0 scsi status 0x0 srb
> > status 0x20 length 36
> > [1.352913] inquiry data: : 00 aa be f1 5c 98 ff ff f0 64
> > 02
Dexuan has reproduced the same problem and discovered that is related to
whether virtual DVD is
attached to the VM. My VM had empty virtual DVD (offline) from the
installation of the ISO.
If the DVD device is removed then the VM boots.
This makes the problem less of a catastrophic but we still
On Tue, Feb 28, 2017 at 10:48:45PM -0800, Stephen Hemminger wrote:
> Let me know, I can run another test and dump more data.
Could it be that we keep the old sense buffer values around because
my commit change the way how sense buffers are handled. A while ago
I suggested this patch to fix it, so
On Wed, 1 Mar 2017 16:50:57 +0100
Christoph Hellwig wrote:
> On Tue, Feb 28, 2017 at 10:48:45PM -0800, Stephen Hemminger wrote:
> > Let me know, I can run another test and dump more data.
>
> Could it be that we keep the old sense buffer values around because
> my commit change the way how sen
On Tue, 28 Feb 2017 22:20:58 -0800
James Bottomley wrote:
> On Tue, 2017-02-28 at 17:25 -0800, Stephen Hemminger wrote:
> > [1.346023] hv_storvsc: IO cmd 0x12 0x0 0x0 scsi status 0x0 srb
> > status 0x20 length 36
> > [1.352913] inquiry data: : 00 aa be f1 5c 98 ff ff f0 64
> > 02
On Tue, 2017-02-28 at 17:25 -0800, Stephen Hemminger wrote:
> [1.346023] hv_storvsc: IO cmd 0x12 0x0 0x0 scsi status 0x0 srb
> status 0x20 length 36
> [1.352913] inquiry data: : 00 aa be f1 5c 98 ff ff f0 64
> 02 89 ff ff ff ff
> [1.356543] inquiry data: 0010: 00 00 00 00 0
On Tue, 2017-02-28 at 10:41 -0800, Stephen Hemminger wrote:
> [1.652279] hv_storvsc: IO cmd 0x12 0x0 0x0 scsi status 0x0 srb
> status 0x20 length 36
> [1.652297] scsi host1: scsi scan: INQUIRY result too short (5),
> using 36
This is definitive. We sent the Inquiry command, we got 36 byt
On Tue, 2017-02-28 at 10:57 -0800, Stephen Hemminger wrote:
> On Tue, 28 Feb 2017 09:06:13 -0800
> James Bottomley wrote:
>
> > On Tue, 2017-02-28 at 08:32 -0700, Jens Axboe wrote:
> > > On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
> > > > On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen H
> Let's concentrate on INQUIRY since that's the first command in the
> probe sequence. I think it's completing successfully because your
> hyperv layer says it has 36 bytes of transfer and that's the size of a
> successful initial INQUIRY, so the fact that the code above would break
> stuff if th
On Tue, 28 Feb 2017 09:06:13 -0800
James Bottomley wrote:
> On Tue, 2017-02-28 at 08:32 -0700, Jens Axboe wrote:
> > On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
> > > On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
> > > > Fixes: ee5242360424 ("scsi: zero per-cmd drive
On Tue, 28 Feb 2017 09:06:13 -0800
James Bottomley wrote:
> On Tue, 2017-02-28 at 08:32 -0700, Jens Axboe wrote:
> > On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
> > > On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
> > > > Fixes: ee5242360424 ("scsi: zero per-cmd drive
On Tue, 28 Feb 2017 09:06:13 -0800
James Bottomley wrote:
> On Tue, 2017-02-28 at 08:32 -0700, Jens Axboe wrote:
> > On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
> > > On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
> > > > Fixes: ee5242360424 ("scsi: zero per-cmd drive
On 02/28/2017 10:16 AM, Stephen Hemminger wrote:
> On Tue, 28 Feb 2017 09:06:13 -0800
> James Bottomley wrote:
>
>> On Tue, 2017-02-28 at 08:32 -0700, Jens Axboe wrote:
>>> On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
On Tue, 28 Feb 2017 15:08:12 +0100
Christoph Hellwig wrote:
> On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
> > Fixes: ee5242360424 ("scsi: zero per-cmd driver data before each I/O")
> >
> > but that is already in linux-next.
> >
> > Noticed another place where memset(of th
On Tue, 2017-02-28 at 08:32 -0700, Jens Axboe wrote:
> On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
> > On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
> > > Fixes: ee5242360424 ("scsi: zero per-cmd driver data before each
> > > I/O")
> > >
> > > but that is already in linux
On 02/28/2017 07:08 AM, Christoph Hellwig wrote:
> On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
>> Fixes: ee5242360424 ("scsi: zero per-cmd driver data before each I/O")
>>
>> but that is already in linux-next.
>>
>> Noticed another place where memset(of the data was being don
On Mon, Feb 27, 2017 at 05:19:31PM -0800, Stephen Hemminger wrote:
> Fixes: ee5242360424 ("scsi: zero per-cmd driver data before each I/O")
>
> but that is already in linux-next.
>
> Noticed another place where memset(of the data was being done not the extra
> bits.
> Tried this, but didn't fix
On 02/27/2017 06:19 PM, Stephen Hemminger wrote:
> On Mon, 27 Feb 2017 15:30:30 -0800
> Stephen Hemminger wrote:
>
>> Something in SCSI in 4.11 broke booting on Hyper-V Generation 2 VM with 8
>> VCPU and 4G of memory.
>> Both Linus's current tree (4.11 pre-rc1) and linux-next fail in a similar
On Mon, 27 Feb 2017 15:30:30 -0800
Stephen Hemminger wrote:
> Something in SCSI in 4.11 broke booting on Hyper-V Generation 2 VM with 8
> VCPU and 4G of memory.
> Both Linus's current tree (4.11 pre-rc1) and linux-next fail in a similar
> manner. It looks like some error
> in SCSI device detect
On 08/01/2013 06:04 PM, Nix wrote:
On 1 Aug 2013, Bernd Schubert verbalised:
On 07/30/2013 11:20 PM, Nix wrote:
On 30 Jul 2013, Bernd Schubert told this:
On 07/30/2013 02:56 AM, Nix wrote:
On 30 Jul 2013, Douglas Gilbert outgrape:
Please supply the information that Martin Petersen asked
f
On 1 Aug 2013, Bernd Schubert verbalised:
> On 07/30/2013 11:20 PM, Nix wrote:
>> On 30 Jul 2013, Bernd Schubert told this:
>>
>>> On 07/30/2013 02:56 AM, Nix wrote:
On 30 Jul 2013, Douglas Gilbert outgrape:
> Please supply the information that Martin Petersen asked
> for.
>
On 07/30/2013 11:20 PM, Nix wrote:
On 30 Jul 2013, Bernd Schubert told this:
On 07/30/2013 02:56 AM, Nix wrote:
On 30 Jul 2013, Douglas Gilbert outgrape:
Please supply the information that Martin Petersen asked
for.
Did it in private IRC (the advantage of working for the same division of
t
On 07/31/2013 05:15 AM, Martin K. Petersen wrote:
>> "Bernd" == Bernd Schubert writes:
>
> Bernd,
>
>>> Product revision level: R001
>
> It's clearly not verbatim passthrough...
>
> Bernd> Besides the firmware, the difference might be that I'm exporting
> Bernd> single disks without any a
> "Nick" == Nick Alcock writes:
Nick> in which case we don't actually know that your Areca controller
Nick> supports the VPD page we thought it did: quite possibly only this
Nick> underlying disk does.
The ATA Information VPD page is created by the SCSI-ATA Translation
layer. The controller
> "Bernd" == Bernd Schubert writes:
Bernd,
>> Product revision level: R001
It's clearly not verbatim passthrough...
Bernd> Besides the firmware, the difference might be that I'm exporting
Bernd> single disks without any areca-raidset in between. I can try to
Bernd> confirm that tomorrow,
> "Doug" == Douglas Gilbert writes:
Doug> I just examined a more recent Areca SAS RAID controller and would
Doug> describe it as the SCSI device from hell. One solution to this
Doug> problem is to modify the arcmsr driver so it returns a more
Doug> consistent set of lies to the management SCS
On 30 Jul 2013, Bernd Schubert told this:
> On 07/30/2013 01:34 AM, Martin K. Petersen wrote:
>> (wheezy)fslab1:~# sg_inq -v /dev/sdc
>> inquiry cdb: 12 00 00 00 24 00
>> standard INQUIRY:
>> inquiry cdb: 12 00 00 00 60 00
>> PQual=0 Device_type=0 RMB=0 version=0x05 [SPC-3]
>> [AER
On 30 Jul 2013, Bernd Schubert told this:
> On 07/30/2013 02:56 AM, Nix wrote:
>> On 30 Jul 2013, Douglas Gilbert outgrape:
>>
>>> Please supply the information that Martin Petersen asked
>>> for.
>>
>> Did it in private IRC (the advantage of working for the same division of
>> the same company!)
On 07/30/2013 02:56 AM, Nix wrote:
On 30 Jul 2013, Douglas Gilbert outgrape:
Please supply the information that Martin Petersen asked
for.
Did it in private IRC (the advantage of working for the same division of
the same company!)
I didn't realise the original fix was actually implemented to
On 07/30/2013 01:34 AM, Martin K. Petersen wrote:
"Nix" == Nix writes:
Bernd,
Nix> I can now confirm that reverting this commit causes this problem to
Nix> go away, and my machine boots fine again.
Can you please send me the output of sq_inq with your 1.49 firmware?
I made a tweak that all
On 30 Jul 2013, Douglas Gilbert outgrape:
> Please supply the information that Martin Petersen asked
> for.
Did it in private IRC (the advantage of working for the same division of
the same company!)
I didn't realise the original fix was actually implemented to allow
Bernd, with a different Arec
On 13-07-29 05:09 PM, Nix wrote:
On 29 Jul 2013, Bernd Schubert uttered the following:
On 07/29/2013 03:05 PM, Nix wrote:
On 29 Jul 2013, Bernd Schubert said:
Hi Nick,
On 07/29/2013 12:10 PM, Nick Alcock wrote:
arcmsr0: abort device command of scsi id = 0 lun = 1
arcmsr0: abort device comm
> "Nix" == Nix writes:
Bernd,
Nix> I can now confirm that reverting this commit causes this problem to
Nix> go away, and my machine boots fine again.
Can you please send me the output of sq_inq with your 1.49 firmware?
I made a tweak that allowed Nix to boot but we're trying to find a goo
On 29 Jul 2013, Bernd Schubert uttered the following:
> On 07/29/2013 03:05 PM, Nix wrote:
>> On 29 Jul 2013, Bernd Schubert said:
>>
>>> Hi Nick,
>>>
>>> On 07/29/2013 12:10 PM, Nick Alcock wrote:
arcmsr0: abort device command of scsi id = 0 lun = 1
arcmsr0: abort device command of scsi
> "Nix" == Nix writes:
Nix> spindle:/boot# sg_vpd --page=0x89 /dev/sda ATA information VPD
Nix> page: fetching VPD page failed
Please add -v
I'll also need the output of:
# sg_vpd -vl
Nix> I'll try rebooting into a kernel with that commit reverted next.
Doesn't matter as far as the sg
On 29 Jul 2013, Bernd Schubert spake thusly:
> Could you try to run these commands with 3.10.1?
>
> # # check if reporting opcodes works
> # sg_opcodes -v -n /dev/sdX
spindle:/boot# sg_opcodes -v -n /dev/sda
inquiry cdb: 12 00 00 00 24 00
Report Supported Operation Codes cmd: a3 0c 00 00
On 29 Jul 2013, Bernd Schubert spake thusly:
> On 07/29/2013 03:05 PM, Nix wrote:
>> On 29 Jul 2013, Bernd Schubert said:
>>> I tested this patch with ARC-1260 and F/W V1.49, no issues. Also, this
>>> patch is only in 3.10.3, but not yet in 3.10.1.
>>
>> ... and I see this problem with 3.10.3 but
> "Bernd" == Bernd Schubert writes:
Bernd> I tested this patch with ARC-1260 and F/W V1.49, no issues.
It could be due to the firmware version discrepancy.
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the b
> "Nick" == Nick Alcock writes:
Nick> My server's ARC-1210 has been working fine for years, but when I
Nick> upgraded from 3.10.1, it started failing:
Nick> [ 0.784044] Areca RAID Controller0: F/W V1.46 2009-01-06 & Model
Nick> ARC-1210 [ 0.804028] scsi0 : Areca SATA Host Adapter RAID
Nick>
On 07/29/2013 03:05 PM, Nix wrote:
On 29 Jul 2013, Bernd Schubert said:
Hi Nick,
On 07/29/2013 12:10 PM, Nick Alcock wrote:
arcmsr0: abort device command of scsi id = 0 lun = 1
arcmsr0: abort device command of scsi id = 0 lun = 0
arcmsr: executing bus reset eh.num_resets=0, num_[...]
arc
On 29 Jul 2013, Bernd Schubert said:
> Hi Nick,
>
> On 07/29/2013 12:10 PM, Nick Alcock wrote:
>> arcmsr0: abort device command of scsi id = 0 lun = 1
>> arcmsr0: abort device command of scsi id = 0 lun = 0
>> arcmsr: executing bus reset eh.num_resets=0, num_[...]
>>
>> arcmsr0: wait 'abort al
Hi Nick,
On 07/29/2013 12:10 PM, Nick Alcock wrote:
My server's ARC-1210 has been working fine for years, but when I
upgraded from 3.10.1, it started failing:
Instead of
[0.784044] Areca RAID Controller0: F/W V1.46 2009-01-06 & Model ARC-1210
[0.804028] scsi0 : Areca SATA Host Adapter
My server's ARC-1210 has been working fine for years, but when I
upgraded from 3.10.1, it started failing:
Instead of
[0.784044] Areca RAID Controller0: F/W V1.46 2009-01-06 & Model ARC-1210
[0.804028] scsi0 : Areca SATA Host Adapter RAID Controller
Driver Version 1.20.00.15 2010/08/05
[
69 matches
Mail list logo
