Re: hang in tstile with Samsung Galaxy

[Christoph Egger <Christoph_Egger%gmx.de@localhost>]

On 09.04.10 15:12, Andrew Doran wrote:
> On Fri, Apr 09, 2010 at 03:03:06PM +0200, Christoph Egger wrote:
>> On 09.04.10 14:55, Manuel Bouyer wrote:
>>> On Fri, Apr 09, 2010 at 11:36:44AM +0200, Christoph Egger wrote:
>>>> sleepq_block+0xcd
>>>> turnstile_block+0x2dd
>>>> mutex_enter+0x26b
>>>
>>> Its it waiting on sd->sc_dk.dk_openlock ?
>>> What does sdopen+0x7a point to ?
>>
>> It points to sys/dev/scsipi/sd.c:409
>>
>>     if (sd->sc_dk.dk_nwedges != 0 && part != RAW_PART) {
>>
>> Right above that line is
>>
>>     mutex_enter(&sd->sc_dk.dk_openlock);
>>
>> so yes, it actually seems to wait for this lock.
>>
>>>
>>>> sdopen+0x7a
>>>> cdev_open+0x63
>>>> spec_open+0x169
>>>> VOP_OPEN+0x62
>>>> vn_open+0x1fc
>>>> sys_open+0xd7
>>>> syscall+0xaa
>>>>
>>
>>
>> Christoph
>>
> 
> The address of that lock will be in the wchan for the process hung in
> tstile.  Do 'show lock ...' on it in DDB and it will tell you who holds
> it (LWP address to pass to t/a command) and where it is held (pass ot
> x/I do get location of the lock acquire).

db> show lock 0xffff80004f2ffd90
lock address : 0xffff80004f2ffd90 type      :     sleep/adaptive
initialiyed  : 0xffffffff806947f2
shared holds :                  0 exclusive :                  1
shares wanted:                  0 exclusive :                  1
current cpu  :                  0 last held :                  0
current lwp  : 0xffff80004b272c00 last held : 0xffff80004ede1800
last locked  : 0xffffffff80651c61 unlocked  : 000000000000000000
owner field  : 0xffff80004ede1800 wait/spin :                1/0

Turnstile chain at 0xffffffff80e31c80.
=> Turnstile at 0xffff80004e645548 (wrq=0xffff80004e645568,
rdq=0xffff80004e645578).
=> 0 waiting readers:
=> 1 waiting writers: 0xffff80004efc5800
db> tr /a 0xffff80004ede1800
trace: pid 0 lid 57 at 0xffff80004eceb600
sleepq_block+0xcd
cv_wait+0x115
scan_mbr+0x39
readdisklabel+0x143
sdopen+0x2fe
bdev_open+0x64
spec_open+0x346
VOP_OPEN+0x62
dkwedge_discover+0xda
sdattach+0x1f2
config_attach_loc+0x16d
scsi_probe_bus+0x4d2
scsibus_config+0x80
scsipi_completion_thread+0x23
db> ps /l
PID  LID S CPU FLAGS  STRUCT LWP *     NAME     WAIT
8680   1 3   0     0 ffff80004efc5800 disklabel tstile
[...]
0     57 3   0   200 ffff80004ede1800  scsibus0 biowait

on prompt:

gdb netbsd.gdb
list *(0xffffffff80651c61)
0xffffffff80651c61 is in sdopen (sys/dev/scsipi/sd.c:409).

So it the lock has already been locked at the same place.

Christoph