Re: SCSI regression

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: >

Re: SCSI regression

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" >

Re: SCSI regression

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

Re: SCSI regression

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

SCSI regression

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

Re: SCSI regression in 4.11

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: >

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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,

Re: SCSI regression in 4.11

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,

Re: SCSI regression in 4.11

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:

Re: SCSI regression in 4.11

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: > > > > > > > >

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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: > > > > [

Re: SCSI regression in 4.11

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: > > >

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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 > [

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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 > >

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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,

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

> 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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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,

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: SCSI regression in 4.11

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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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. Did it in private IRC (the

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/31/2013 05:15 AM, Martin K. Petersen wrote: Bernd == Bernd Schubert bernd.schub...@fastmail.fm 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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

On 07/30/2013 01:34 AM, Martin K. Petersen wrote: Nix == Nix n...@esperi.org.uk 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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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!) I didn't

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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] [AERC=0]

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

Bernd == Bernd Schubert bernd.schub...@fastmail.fm 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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

Nick == Nick Alcock nick.alc...@esperi.org.uk 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.

[SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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 all

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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_[...]

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

Nick == Nick Alcock n...@esperi.org.uk 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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

Bernd == Bernd Schubert bernd.schub...@fastmail.fm 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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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 not 3.10.1.

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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 00

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

Nix == Nix n...@esperi.org.uk 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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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 id = 0 lun = 0

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

Nix == Nix n...@esperi.org.uk 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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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

Re: [SCSI REGRESSION] 3.10.2 or 3.10.3: arcmsr failure at bootup / early userspace transition

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 Areca