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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87siyvlhgs.fsf@spindle.srvr.nix>
Date:	Wed, 31 Jul 2013 01:07:47 +0100
From:	Nick Alcock <nick.alcock@...eri.org.uk>
To:	Bernd Schubert <bernd.schubert@...tmail.fm>
Cc:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-scsi@...r.kernel.org, nick.cheng@...ca.com.tw,
	stable@...r.kernel.org
Subject: 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]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=2
>>   SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=0  BQue=0
>>   EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=1
>>   [RelAdr=0]  WBus16=1  Sync=0  Linked=0  [TranDis=0]  CmdQue=1
>>   [SPI: Clocking=0x3  QAS=0  IUS=0]
>>     length=96 (0x60)   Peripheral device type: disk
>>  Vendor identification: Hitachi
>>  Product identification: HDS724040KLSA80
>>  Product revision level: R001
>>     inquiry cdb: 12 01 00 00 fc 00
>>     inquiry cdb: 12 01 80 00 fc 00
>>  Unit serial number: KRFS2CRAHXJZVD
>
> Besides the firmware, the difference might be that I'm exporting single disks without any areca-raidset in between.
> I can try to confirm that tomorrow, I just need the system as it is till tomorrow noon.

Aaah. Yeah, it looks like in JBOD mode it's just passing things straight
on to the disk: that vendor ID is a dead giveaway. For all I know my
earlier firmware does the same, but for obvious reasons I can't really
test that! Quite possibly it's passing *everything* on to the disk,
including all SCSI commands, in which case we don't actually know that
your Areca controller supports the VPD page we thought it did: quite
possibly only this underlying disk does.

You can get a degree of info on the underlying disks in the array even
if it's in RAID mode -- smartctl does it, for instance -- but it takes
Areca-specific code and chattering to the sg devices directly. I bet
that in JBOD mode, the sg device is the only exposure the controller has
to the world, and *all* the /dev/sd* devices are just passthroughs.

-- 
NULL && (void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/