tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: hang in tstile with Samsung Galaxy



On Fri, Apr 09, 2010 at 03:40:15PM +0200, Christoph Egger wrote:
> 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

So this biowait is your real hang, the tstile is just incidental..
It's hanging trying to read the partition tables from the disk.
Presumably it has issued an I/O and the disk does not respond.
If I wanted to debug this further, I'd be looking at turning on
debugging in the USB and SCSI layers to see what's happening.

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


Home | Main Index | Thread Index | Old Index