[Was USB; is] dkwedge_add(), 6.1.5/amd64: freezes when 2 umass connected

[tlaronde%polynum.com@localhost]

On Thu, Jul 02, 2015 at 11:07:19AM +0200, tlaronde wrote:
> 
> On an NetBSD 6.1.5/amd64, when I connect a second USB connected disk to
> the machine, NetBSD freezes. Unable to connect remotely; hard reboot
> required.
> 

Indeed, the system doesn't freeze but crashes (some long time without
response is caused by backtracing but this can only be seen on the
console).

When a first USB disk is connected (umass0), adding another USB disk
crashes everything. Here are the excerpts from dmesg for the crash:

---8<---
umass0: at uhub3 port 1 (addr 3) disconnected
umass0 at uhub3 port 1 configuration 1 interface 0
umass0: Western Digital Elements 10A2, rev 2.10/10.42, addr 3
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <WD, Elements 10A2, 1042> disk fixed
sd0: fabricating a geometry
sd0: 931 GB, 953837 cyl, 64 head, 32 sec, 512 bytes/sect x 1953458176 sectors
sd0: fabricating a geometry
sd0: GPT GUID: 960d762c-1cf3-11e5-b5f3-448a5b9b9f0f
dk0 at sd0: Basic data partition
dk0: 1953454080 blocks at 2048, type: 
umass1 at uhub2 port 6 configuration 1 interface 0
umass1: Western Digital Elements 10A8, rev 2.10/10.42, addr 3
umass1: using SCSI over Bulk-Only
scsibus1 at umass1: 2 targets, 1 lun per target
sd1 at scsibus1 target 0 lun 0: <WD, Elements 10A8, 1042> disk fixed
sd1(umass1:0:0:0):  Check Condition on CDB: 0x00 00 00 00 00 00
    SENSE KEY:  Not Ready
     ASC/ASCQ:  Logical Unit Is in Process Of Becoming Ready

sd1: drive offline
sd1: fabricating a geometry
sd1: GPT GUID: f3d6ceb3-2183-11e5-8a35-448a5b9b9f0f
sd1: detached
uvm_fault(0xffffffff80771320, 0x0, 1) -> e
fatal page fault in supervisor mode
trap type 6 code 0 rip ffffffff80238c1f cs 8 rflags 10287 cr2  8 cpl 0 rsp fffffe81111976b0
panic: trap
cpu1: Begin traceback...
printf_nolog() at netbsd:printf_nolog
startlwp() at netbsd:startlwp
alltraps() at netbsd:alltraps+0x96
dkwedge_add() at netbsd:dkwedge_add+0x1d1
dkwedge_discover_gpt() at netbsd:dkwedge_discover_gpt+0x492
dkwedge_discover() at netbsd:dkwedge_discover+0x128
sdattach() at netbsd:sdattach+0x1cb
config_attach_loc() at netbsd:config_attach_loc+0x1bb
scsi_probe_bus() at netbsd:scsi_probe_bus+0x537
scsibus_config() at netbsd:scsibus_config+0x74
scsipi_completion_thread() at netbsd:scsipi_completion_thread+0x23
cpu1: End traceback...
--->8---

Dropping in ddb on panic, more precisely there is:

Stopped in pid 1.57 (system) at netbsd:mutex_vector_enter+0x80: movq 18(%r15),%rax

This has nothing to do with MBR or GPT since I have tested with both. It
is systematic whenever one disk is first connected and then a second is
added.

Once rebooted, the two disks being connected, they are both correctly
accessible.

Note: FWIW, the first (and sole) disk is sd0. When rebooting, the
device nodes are reversed, the second one being sd0 and the first
one being sd1.

Question: is there some way to named partitions independantly from
hardware random enumeration (via wedges names? But this would imply
keeping persistently the name, so I guess in the GPT? Is there such 
a thing?)

-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C