On 21 February 2011 18:53, Nemo nemo.m...@gmail.com wrote:
i reply myself; i think they use sst to mix multimedia streams, and
in that case a lost packet in one stream (say text) would
delay other streams (say audio) that do not need to be delayed if
you use sst.
But otherwise I still think
i've also been experimenting with a 9p modification that
suggested some while ago, allowing multiple outstanding
requests to be queued in sequence. it works, but the code
still needs quite a bit of polishing.
queued or sent?
- erik
On 22 February 2011 13:25, erik quanstrom quans...@quanstro.net wrote:
i've also been experimenting with a 9p modification that
suggested some while ago, allowing multiple outstanding
requests to be queued in sequence. it works, but the code
still needs quite a bit of polishing.
queued or
I'm struggling to understand the ins and outs of the usb ohci driver
(usbohci.c) and have a question (well, several).
If one writes to an endpoint, then epio gets called. This in turn
does ilock(ctrl) which disables interrupts on my single-processor
machine. Then epgettd is called several times
I'll look again (just did).
But I think you found a bug.
On Tue, Feb 22, 2011 at 4:10 PM, r...@hemiola.co.uk wrote:
I'm struggling to understand the ins and outs of the usb ohci driver
(usbohci.c) and have a question (well, several).
If one writes to an endpoint, then epio gets called. This
Hello,
A 'page-in' occurs on page fault exception, which cannot be masked.
Phil;
Le 22/02/2011 16:10, r...@hemiola.co.uk a écrit :
I'm struggling to understand the ins and outs of the usb ohci driver
(usbohci.c) and have a question (well, several).
If one writes to an endpoint, then epio
Oh, sorry, I forgot that the page-in operation might require an interrupt
from the disk or network controller in order to reload the page.
Phil;
Le 22/02/2011 16:31, Philippe Anel a écrit :
Hello,
A 'page-in' occurs on page fault exception, which cannot be masked.
Phil;
Le 22/02/2011
But I think you found a bug.
Ok, so maybe the first ilock/iunlock pair isn't needed? The controller
can't see the task descriptors that have been chained on to the
endpoint until the tail element of the endpoint descriptor is set,
so any potential interrupts during the sequence won't affect
In general, there are more ilocks than needed, out of paranoia.
I don't have the code here now, but you might be right.
thanks
On Tue, Feb 22, 2011 at 5:42 PM, r...@hemiola.co.uk wrote:
But I think you found a bug.
Ok, so maybe the first ilock/iunlock pair isn't needed? The controller
can't
May I have one more question?
When you create a new bulk or interrupt endpoint epopen is called.
The aux field of the Ep is set to point to an array of two Qio
structures. One for input and one for output. Both of those in turn
have a pointer to, and a one-to-one correspondence with, an endpoint
We don't follow the spec that close. I think linux calls this pipes,
but I'm not sure now. In any case, IIRC, we could do I/O on
those eps [but I'm kind of sleepy now and don't have the code at hand,
so don't trust me too much on this; I can double check later if you
want me to do that.]
On the
(note that the std would call each simplex chan an endpoint, but
you can pair two of them and consider them an endpoint when they are duplex)
As an example, I have a usb device which presents both an input
endpoint #2 and an output endpoint #2. The standard would treat these
as separate
On Mon, Feb 21, 2011 at 5:45 PM, erik quanstrom quans...@quanstro.net wrote:
ah yes, that clears it up
19.4.22
APICID
This register uniquely identifies an APIC in the system. This register
is not used by
OS'es anymore and is still implemented in hardware because
On Tue Feb 22 12:57:18 EST 2011, rminn...@gmail.com wrote:
On Mon, Feb 21, 2011 at 5:45 PM, erik quanstrom quans...@quanstro.net wrote:
ah yes, that clears it up
19.4.22
APICID
This register uniquely identifies an APIC in the system. This
register is not used by
Beware that numbers as shown by plan 9 might not be those shown by linux, for
example. In any case, it can differ for different devices, although most of them
look the same if they are of the same kind.
On Tue, Feb 22, 2011 at 6:39 PM, r...@hemiola.co.uk wrote:
presents both an input endpoint
19.4.22
APICID
This register uniquely identifies an APIC in the system. This
register is not used by
OS'es anymore and is still implemented in hardware because of FUD.
(Intel® 5520 chipset and Intel® 5500 chipset datasheet pub 321328)
Did
let me ask the question again. I know what the difference between APIC
and ACPI means.
Why is it that they don't think anyone needs that register any more?
What are they suggesting people use instead?
ron
On Tue Feb 22 15:11:29 EST 2011, rminn...@gmail.com wrote:
let me ask the question again. I know what the difference between APIC
and ACPI means.
i wasn't implying that you didn't. i was saying that i sometimes
think one and say the other.
Why is it that they don't think anyone needs that
apic ids can be found in the madt table, from acpi, iirc.
On Feb 22, 2011, at 9:27 PM, erik quanstrom quans...@quanstro.net wrote:
On Tue Feb 22 15:11:29 EST 2011, rminn...@gmail.com wrote:
let me ask the question again. I know what the difference between APIC
and ACPI means.
i wasn't
apic ids can be found in the madt table, from acpi, iirc.
Heh. You assume a correct ACPI BIOS implementation. The worst
offenders I've seen have been Intel-designed motherboards :-P
On Tue Feb 22 15:48:01 EST 2011, lyn...@orthanc.ca wrote:
Heh. You assume a correct ACPI BIOS implementation. The worst
offenders I've seen have been Intel-designed motherboards :-P
On Tue Feb 22 15:39:49 EST 2011, nemo.m...@gmail.com wrote:
apic ids can be found in the madt table, from
the madt table or the mp tables reflect a snaphot of *all*
the i/o apics and lapics in the system at the time when bios handed
control over to the operating system (sic.).
No it doesn't. That's the bug in the BIOS -- it screws up building
the table. I have an Intel mini-ITX board sitting in a
On Tue Feb 22 15:58:12 EST 2011, lyn...@orthanc.ca wrote:
the madt table or the mp tables reflect a snaphot of *all*
the i/o apics and lapics in the system at the time when bios handed
control over to the operating system (sic.).
No it doesn't. That's the bug in the BIOS -- it screws up
by definition, a bug in your bios doesn't change the specification,
True. But a specification that doesn't run the same way on any
two models of motherboard isn't much of one.
24 matches
Mail list logo
