[9fans] ehci/uhci interrupts

[9fans] ehci/uhci interrupts

[erik quanstrom]

it appears that uhci is causing spurious ehci interrupts, or at least
ehci/uhci are causing each other to ring.  i haven't tracked down
the fundamental issue yet.  but this appears to be related to the
ehci/uhci subordinate issue, and the Callmine setting.

hacking details for the interested:

when i limit one particular machine to 5 uhci controllers, everything
is fine.  one suspects that this is luck due to whatever it is that triggers
the excitement being connected to the 6th controller.  the 6th controller
does indeed share an interrupt with ehci.  if it were enabled it would be
70.1/10.

(nix uses vector.mach notation for /dev/irqalloc.  since the amd64
port of the nix kernel has settled on physical interrupt addressing,
a machine may have nmach*nvector available vectors.)

juno# grep usb /dev/irqalloc
       68.0          15                    0                    0 ioapic   usbuhci
       68.1           7                    0                    0 ioapic   usbuhci
       68.2          11                    0                    0 ioapic   usbuhci
       68.2          11                    0                    0 ioapic   usbuhci
>      68.3           6                    2                11136 ioapic   usbehci
>      68.3           6                    0                    0 ioapic   usbuhci
       70.1          10                    0                    0 ioapic   usbehci

- erik

Re: [9fans] ehci/uhci interrupts

[erik quanstrom]

On Fri May  2 11:28:41 EDT 2014, quanstro@quanstro.net wrote:
> it appears that uhci is causing spurious ehci interrupts, or at least
> ehci/uhci are causing each other to ring.  i haven't tracked down
> the fundamental issue yet.  but this appears to be related to the
> ehci/uhci subordinate issue, and the Callmine setting.

problem found.  patch appled.  if a ehci controller is 64-bit capable,
one must turn off 64-bit capabilities on all controllers before initializing
any of them.

- erik

Re: [9fans] ehci/uhci interrupts

[lucio]

> problem found.  patch appled.  if a ehci controller is 64-bit capable,
> one must turn off 64-bit capabilities on all controllers before initializing
> any of them.

Well done, Erik!  Keep the posts coming, even if no one provides any
feedback; your efforts are appreciated, even if I speak only for
myself.

++L

Re: [9fans] ehci/uhci interrupts

[tlaronde]

On Sat, May 03, 2014 at 07:14:34AM +0200, lucio@proxima.alt.za wrote:
>
> > problem found.  patch appled.  if a ehci controller is 64-bit capable,
> > one must turn off 64-bit capabilities on all controllers before initializing
> > any of them.
>
> Well done, Erik!  Keep the posts coming, even if no one provides any
> feedback; your efforts are appreciated, even if I speak only for
> myself.

Same here. I'm silent---because I have nothing interesting to say---but
I'm listening and being ashamed of not doing enough. This simply put
higher the ones who do.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                      http://www.kergis.com/
              http://www.renaissance-francaise.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] ehci/uhci interrupts

[erik quanstrom]

On Sat May  3 05:42:00 EDT 2014, tlaronde@polynum.com wrote:
> On Sat, May 03, 2014 at 07:14:34AM +0200, lucio@proxima.alt.za wrote:
> >
> > > problem found.  patch appled.  if a ehci controller is 64-bit capable,
> > > one must turn off 64-bit capabilities on all controllers before initializing
> > > any of them.
> >
> > Well done, Erik!  Keep the posts coming, even if no one provides any
> > feedback; your efforts are appreciated, even if I speak only for
> > myself.
>
> Same here. I'm silent---because I have nothing interesting to say---but
> I'm listening and being ashamed of not doing enough. This simply put
> higher the ones who do.

thanks!  as i should thank a lot of other people.

there are lots of small ways to improve things, too.  i'd be happy
to talk about that on or off list.  one thing that immediately springs
to mind is additions to charles' kernel man pages.

- erik

Re: [9fans] ehci/uhci interrupts

[lucio]

> there are lots of small ways to improve things, too.  i'd be happy
> to talk about that on or off list.  one thing that immediately springs
> to mind is additions to charles' kernel man pages.

The list is not very busy and, I hate to admit, somewhat remote from
Bell Labs.  As a result, I think there would be no serious objection
to add pertinent traffic to it.

Personally, kernel pages would be a god-send (but an update of Nemo's
commentaries would be even more so) and I would like to add discussion
on the various Plan 9 flavours and how their differences should be
consolidated or, if necessary, properly set down as distinguishing
features.

The same for patches that have not yet been accepted in the Bell Labs
release, I believe they ought to be discussed here with a view to make
them conform, where necessary, to Bell Labs' specifications so they
can be incorporated.

Maybe the long term discussions belong elesewhere, but right now, here
is where we all are.

++L

Re: [9fans] ehci/uhci interrupts

[tlaronde]

On Sun, May 04, 2014 at 07:12:10AM +0200, lucio@proxima.alt.za wrote:
>
> Personally, kernel pages would be a god-send

Despite what one might think at first, writing documentation is not
easier than writing code, and is, IMHO, harder. To write good manual
pages---the Bell Labs man pages are simply great and from reading the
man pages one knows that the ones who wrote the code knew what they were
doing---is difficult. One can have the code done, sort of "working",
without being able to explain to humans exactly why he has done
the things this way or without being able to explain all he had in
mind---things that subconsciously drove the implementation.

I know that now, I start by "explaining" to me what I want to
achieve and critize or "ask" myself the axiomatic, before indeed
starting to implement---after, for the details, it is a dialog between
theory and code. So now the doc and man pages appear first.
Not after. And I'm verifying that the code conforms to what it was
supposed to achieve (it's not as obvious as it may seem).

And there is the problem of the tong. I know that when I tried to
wrote directly into "english", it was a disaster. I have written
the same library---in CWEB that is literate programming; code in
C, explanations formated with TeX---first in english, after in
french, and the result in english was nonsense for the explanations
and code that worked, sort of, but had remote link (hopefully) with
the explanations. Rewriten in french, both explanations and code
improved, simply because I could directly map what I had in mind
in words without trying to first translate i.e. betray (in italian,
they says "tradutore, traditore") and because it was supposed to
be read by me, first, and not to be a public monument to my supposed
smartness, putting things that had nothing to do there instead on
focusing on the task.

So, IMHO, one embarking in writing manual pages, should start by writing
in one's native tong taking the Bell Labs man pages as an example. And
once there is nothing more to remove and the manual page is considered
good (simplicity is the shortest way to truth), let the translation in
"C" (pseudo-english) begin.

I don't think too that the trafic on the list is too high to forbid,
once somebody has something ready for review, to put a link and to
ask for comments.

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

Re: [9fans] ehci/uhci interrupts

[erik quanstrom]

> Despite what one might think at first, writing documentation is not
> easier than writing code, and is, IMHO, harder. To write good manual
> pages---the Bell Labs man pages are simply great and from reading the

i agree with your points, but i think there are two additional facts to consider.

1.  software is often not intrinsicly hard to write.  the hard bit is the experience
that goes into discovering *what* to write, and which of the many implementation
techniques really wins.

so the skills needed to write the man page differ from the skills needed to
write, and that difference is largely experience, i think you've made an excellent
argument that writing a few man pages is an excellent exercize for anyone,
most especially a gifted student or newcomer to plan 9.

2.  perfection should not be the enemy of good.  if the manual page is
currently missing, a passible man page is better than nothing, so long as
it is humble and doesn't try to explain things that are not properly understood.
which is to say, incomplete is fine, but wrong is not.

> So, IMHO, one embarking in writing manual pages, should start by writing
> in one's native tong taking the Bell Labs man pages as an example. And
> once there is nothing more to remove and the manual page is considered
> good (simplicity is the shortest way to truth), let the translation in
> "C" (pseudo-english) begin.

having lived and worked in a non-english-speaking country, i think this may
vary by individual.  translating back and forth was too much work and too
distracting for me.  additionally, i found the x:y language dictionaries to be
especially inaccurate for technical terms.  in fact, in the professional area i
worked in, to this day, i don't know the field's technical jargon in english.
i never learned it.

an odd thesis that i probablly don't have time to investigate: man pages
are lower vocabulary complexity than natural language, if jargon is set aside.

- erik

Re: [9fans] ehci/uhci interrupts

[tlaronde]

On Sun, May 04, 2014 at 03:29:57PM -0400, erik quanstrom wrote:
>
> having lived and worked in a non-english-speaking country, i think this may
> vary by individual.  translating back and forth was too much work and too
> distracting for me.

I found that if the translation is done once (when the work is more or
less done), it is not a huge burden and it even helps to improve the
native tong paper (ironing out fuzzy wording or discovering a simpler
way to say).

>additionally, i found the x:y language dictionaries to be
> especially inaccurate for technical terms.

FWIW, I know refer to the Elsevier's dictionary of computer science and
mathematics that only gives the vocabulary in 4 languages : english,
german, french, russian. It happens that my native tong is one of them.
Some expressions are impossible to guess or to obtain by raw
translation.

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

Re: [9fans] ehci/uhci interrupts

[erik quanstrom]

> > there are lots of small ways to improve things, too.  i'd be happy
> > to talk about that on or off list.  one thing that immediately springs
> > to mind is additions to charles' kernel man pages.
>
> The list is not very busy and, I hate to admit, somewhat remote from
> Bell Labs.  As a result, I think there would be no serious objection
> to add pertinent traffic to it.
>
> Personally, kernel pages would be a god-send (but an update of Nemo's
> commentaries would be even more so) and I would like to add discussion
> on the various Plan 9 flavours and how their differences should be
> consolidated or, if necessary, properly set down as distinguishing
> features.

these are the current section 9 pages, largely written by charles.
they pertain to all kernels

	allocb conf delay devattach dmainit error eve inb intrenable kbdputc
	kproc lib lock malloc monmwait newchan panic parsecmd qio qlock
	readnum ref seconds sleep splhi uartp8250 xalloc

these are the current section 9nix (an unfortuante distinction that is
hopefully temporary)

	adr panic physalloc qmalloc vmap

the current man pages can be accessed via, e.g.

	http://www.9atom.org/magic/man2html/9/allocb

- erik