From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon,  5 Mar 2012 10:46:01 -0500
To: 9p-st@imu.li, 9fans@9fans.net
Message-ID: <504d1e9e6a08271d15827ea4c00507ff@chula.quanstro.net>
In-Reply-To: <2579b6.8126cb52.62GS.mx@tumtum.plumbweb.net>
References: <2579b6.8126cb52.62GS.mx@tumtum.plumbweb.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] usb slowness
Topicbox-Message-UUID: 668ae184-ead7-11e9-9d60-3106f5b1d025

> cpu% kprof /n/9fat/9cpcpuf /dev/kpdata
> total: 24620	in kernel text: 23890	outside kernel text:730
> RTZERO f0100000 PGSIZE 4Kb
> ms	  %	sym
> 21840	 91.3	_strayintr
> 290	  1.2	memmove
> 290	  1.2	iunlock
> 180	  0.7	sched
> 160	  0.6	memset
> 150	  0.6	sleep

if you could temporarly run a 9atom kernel,
(http://ftp.quanstro.net/other/9pc*.gz), there
are a few things you can do to look at the
problem,

1.  /dev/irqalloc (http://ftp.quanstro.net/magic/man2html/3/arch)
has two additional fields detailing the irq allocation, and time
spent in each interrupt.  unless things are really hosed, this should
tell you what's at fault.  if things are really quite screwed up, you
may be inducing spurious interrupts.  in that case,

2. /dev/mpirq (http://ftp.quanstro.net/magic/man2html/3/apic)
should detail enough of bios reported interrupts to tell if something
is going sideways in interrupt allocation.

unfortunately, i would think that the most likely reason
for this is that usbether/devusb are not tamping down the
interrupt properly.

i've seen this with usb serial.

- erik