Looks like a broken hub? (was Re: 3.16.2: 2TiB Seagate Expansion Desk apparently still broken with both USB mass storage *and* UAS: some debugging output)

On 7 Sep 2014, Alan Stern spake thusly: > On Sun, 7 Sep 2014, Nix wrote: > >> I have a brand new Seagate Expansion Desk drive attached to my x86-64 >> desktop. (I also have a 4TiB model of the same drive, but I haven't even >> unboxed it: there seems little poin

3.16.2: 2TiB Seagate Expansion Desk apparently still broken with both USB mass storage *and* UAS: some debugging output

I have a brand new Seagate Expansion Desk drive attached to my x86-64 desktop. (I also have a 4TiB model of the same drive, but I haven't even unboxed it: there seems little point as long as the 2TiB version doesn't work.) I am seeing apparently the same problem as Alexandre Oliva reported in

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

On 31 Aug 2013, Greg KH said: > On Fri, Aug 30, 2013 at 11:01:56AM +0100, Nix wrote: >> On 1 Aug 2013, Bernd Schubert said: >> >> > Once I noticed that scsi_get_vpd_page() works fine from other function >> > calls and that it is not 0x89, but already 0x0 that

Re: [PATCH] scsi disk: Use its own buffer for the vpd request

On 1 Aug 2013, Bernd Schubert said: > Once I noticed that scsi_get_vpd_page() works fine from other function > calls and that it is not 0x89, but already 0x0 that fails fixing it became > easy. > > Nix, any chance you could verify it also works for you? As an aside, this commit

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

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

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 Arec

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 scs

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

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

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 al