Re: [9fans] streams
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 that muxing a tcp stream might provide something similar (without some of sst ffeatures, i admit) and a lot easier to implement. I'll write a toy to see if this is wrong. i've been playing around with something similar in Go, layering rpc (analogous to 9p) over netchan (analogous to SST), which seems to work quite well, although i haven't done many performance experiments. this by itself doesn't entirely mitigate 9p performance though. there are many sequences of operations that still require multiple unnecessary round trips. 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. the summary is here: http://code.google.com/p/rog-go/source/browse/new9p/doc.txt
Re: [9fans] streams
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
Re: [9fans] streams
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 sent? sent, then queued at the server side if necessary.
[9fans] usb ohci question
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 to allocate transfer descriptors. Each call to epgettd copies a portion from the user space buffer which was passed as a parameter to epio. What happens here if the user space buffer is in a page which is not present? Is it possible for a page-in to happen even when interrupts are disabled by the ilock? Thanks for any insight. rod
Re: [9fans] usb ohci question
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 in turn does ilock(ctrl) which disables interrupts on my single-processor machine. Then epgettd is called several times to allocate transfer descriptors. Each call to epgettd copies a portion from the user space buffer which was passed as a parameter to epio. What happens here if the user space buffer is in a page which is not present? Is it possible for a page-in to happen even when interrupts are disabled by the ilock? Thanks for any insight. rod
Re: [9fans] usb ohci question
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 gets called. This in turn does ilock(ctrl) which disables interrupts on my single-processor machine. Then epgettd is called several times to allocate transfer descriptors. Each call to epgettd copies a portion from the user space buffer which was passed as a parameter to epio. What happens here if the user space buffer is in a page which is not present? Is it possible for a page-in to happen even when interrupts are disabled by the ilock? Thanks for any insight. rod
Re: [9fans] usb ohci question
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 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 gets called. This in turn does ilock(ctrl) which disables interrupts on my single-processor machine. Then epgettd is called several times to allocate transfer descriptors. Each call to epgettd copies a portion from the user space buffer which was passed as a parameter to epio. What happens here if the user space buffer is in a page which is not present? Is it possible for a page-in to happen even when interrupts are disabled by the ilock? Thanks for any insight. rod
Re: [9fans] usb ohci question
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 anything. rod
Re: [9fans] usb ohci question
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 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 anything. rod
[9fans] usb ohci - one more question
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 descriptor (Ed). newed is called for each Qio to link the Qio's endpoint descriptor into the controller's chain. I can't figure out why there are two Qio structs. The usb spec says that bulk/interrupt endpoints are unidirectional, so why wouldn't just a single one do? Thanks, rod
Re: [9fans] usb ohci - one more question
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 other hand, there are so many ep types and transfer types, that it looks easier to follow the same pattern for I/O on all eps, duplex or not (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). On Tue, Feb 22, 2011 at 6:02 PM, r...@hemiola.co.uk wrote: 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 descriptor (Ed). newed is called for each Qio to link the Qio's endpoint descriptor into the controller's chain. I can't figure out why there are two Qio structs. The usb spec says that bulk/interrupt endpoints are unidirectional, so why wouldn't just a single one do? Thanks, rod
Re: [9fans] usb ohci - one more question
(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 endpoints which have the same endpoint number. The Plan 9 driver treats them (sensibly I think) as a single bidirectional endpoint.
Re: [9fans] tech writer humor
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 of FUD. (Intel® 5520 chipset and Intel® 5500 chipset datasheet pub 321328) Did intel claim that the OSes should be using ACPI? What do they use instead? ron p.s. I appreciate the humor but it does lead to a serious question.
Re: [9fans] tech writer humor
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 OS'es anymore and is still implemented in hardware because of FUD. (Intel® 5520 chipset and Intel® 5500 chipset datasheet pub 321328) Did intel claim that the OSes should be using ACPI? What do they use instead? ron p.s. I appreciate the humor but it does lead to a serious question. afik, acpi has nothing to do with this problem. i believe this particular tech writer intends to claim that nobody uses physical addressing anymore. but i believe bios still needs to use physical addressing before logical addressing is established. so i think the writer may be speaking a misleading half of the whole story. - erik
Re: [9fans] usb ohci - one more question
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 #2 and an output endpoint #2 Ah, thanks. I wasn't aware that 2 endpoints could have the same number and be distinct only in their data direction. All of the 20 or so different sticks on my desk have separate endpoint numbers. rod
Re: [9fans] tech writer humor
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 intel claim that the OSes should be using ACPI? What do they use instead? ron p.s. I appreciate the humor but it does lead to a serious question. afik, acpi has nothing to do with this problem. i believe this particular tech writer intends to claim that nobody uses physical addressing anymore. but i believe bios still needs to use physical addressing before logical addressing is established. so i think the writer may be speaking a misleading half of the whole story. i think i was unclear. by physical vs. logical addressing i mean of course of the various system apics, not of memory. in any event, the logical addressing is the responsibility of the os, so acpi doesn't provide it either. (annoying how acpi and apic obvious anagrams.) - erik
Re: [9fans] tech writer humor
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
Re: [9fans] tech writer humor
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 register any more? What are they suggesting people use instead? good question. as i said before, i have to chalk it up to hurried documentation. i'm quite sure apic ids are still important. - erik
Re: [9fans] tech writer humor
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 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 register any more? What are they suggesting people use instead? good question. as i said before, i have to chalk it up to hurried documentation. i'm quite sure apic ids are still important. - erik
Re: [9fans] tech writer humor
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
Re: [9fans] tech writer humor
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 acpi, iirc. neither of these comments apply to the registers in question. the registers in question are the running configuration of the i/o apic in the intel IOH-36D. 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.). - erik
Re: [9fans] tech writer humor
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 box because it's unuseable due to this bug.
Re: [9fans] tech writer humor
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 building the table. I have an Intel mini-ITX board sitting in a box because it's unuseable due to this bug. by definition, a bug in your bios doesn't change the specification, - erik
Re: [9fans] tech writer humor
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.
