Re: user-level drivers
On Mon, May 09, 2011 at 12:07:16AM +0200, Samuel Thibault wrote: > I've started having a look at Zheng Da's user-level driver integration. > I've cleaned his tree a bit, and now considering adding patches to > the debian packages for wider testing. The patches however add a few > kernel RPCs, which we should probably agree on first, at the minimum > that their existence makes sense, so we can reserve slots in upstream > gnumach. Basically, it's about allocating physically-contiguous memory > for DMAs, and getting IRQ events: > > /* > * This routine is created for allocating DMA buffers. > * We are going to get a contiguous physical memory > * and its physical address in addition to the virtual address. > */ > routine vm_allocate_contiguous( > host_priv : host_priv_t; > target_task : vm_task_t; > out vaddr : vm_address_t; > out paddr : vm_address_t; > size: vm_size_t); This RPC lacks a few additional constraints like boundaries, alignment and maybe phase. We may not use them now, but they're important for portability (e.g. if GNU Mach supports PAE, drivers that can't use physical memory beyond the 4 GiB limit must be able to express it). > /* Requesting IRQ events on a port */ > > routine device_intr_notify( >master_port : mach_port_t; >in irq : int; >in id : int; >in flags : int; >in receive_port: mach_port_send_t >); > > The actual event: > > simpleroutine mach_notify_irq( >notify : notify_port_t; >name: int); > > And a way to mask/unmask irqs: > > /* > * enable/disable the specified irq. > */ > routine device_irq_enable( >master_port : mach_port_t; >irq : int; >status : char); > > Should this be rather split into device_irq_enable/disable and drop the > status paramter? Naming a function taht can disable something "xxx_enable" is confusing. By the way, I also think using both "intr" and "irq" is confusing. We should stick with "intr". device_intr_notify() isn't a suitable name as it doesn't make it obvious that it's a registration request. It should rather be named device_intr_establish() or device_intr_register(). Parameters named "irq" could be renamed "line" instead. And we should also follow the way Mach names are built (i.e. module_object_method). mach_notify_irq() could be renamed mach_intr_notify(). device_irq_enable() would be named device_intr_enable(). -- Richard Braun
Re: user-level drivers
Hallo! On Mon, 9 May 2011 00:07:16 +0200, Samuel Thibault wrote: > I've started having a look at Zheng Da's user-level driver integration. > I've cleaned his tree a bit, and now considering adding patches to > the debian packages for wider testing. Great! I'm not the most knowledgeable person to comment on these RPC interfaces, but anyway: > The patches however add a few > kernel RPCs, which we should probably agree on first, at the minimum > that their existence makes sense, so we can reserve slots in upstream > gnumach. Basically, it's about allocating physically-contiguous memory > for DMAs, and getting IRQ events: Of course, it doesn't matter at the moment, but are these for x86 only, or architecture independent? > * This routine is created for allocating DMA buffers. > * We are going to get a contiguous physical memory > * and its physical address in addition to the virtual address. > */ > routine vm_allocate_contiguous( > host_priv : host_priv_t; > target_task : vm_task_t; > out vaddr : vm_address_t; > out paddr : vm_address_t; > size: vm_size_t); Hmm, I guess we don't have anything that is better than using vm_address_t for physical addresses? At least not in include/mach/std_types.h, i386/include/mach/i386/vm_types.h. Should we? (phys_address_t based on natural_t?) At this time, would it make sense to make paddr inout (and/or vaddr, too?) and add an additional ``anywhere : boolean_t'' parameter as vm_allocate has? Or can't there be any need for such functionality? > /* Requesting IRQ events on a port */ > > routine device_intr_notify( >master_port : mach_port_t; >in irq : int; >in id : int; >in flags : int; >in receive_port: mach_port_send_t >); Minor, but I would put the receive_port at the top of the ``in data'' list, after the master_port. Shouldn't all the other ``in data'' items be wrapped in an (architecured-dependent) structure similar to what we're doing for I/O ports? Compare io_perm_t in i386/include/mach/i386/mach_i386.defs, i386/include/mach/i386/mach_i386_types.h, i386/i386/io_perm.h. I believe this would help to separate implementation details (IRQ number being an integer; specific values of flags; etc.) from the RPC mechanism. Especially so if these are architecture independent calls. > The actual event: > > simpleroutine mach_notify_irq( >notify : notify_port_t; >name: int); I don't understand this ``name : int''. Isn't this rather a pointer to a struct mach_irq_notification_t? > And a way to mask/unmask irqs: > > /* > * enable/disable the specified irq. > */ > routine device_irq_enable( >master_port : mach_port_t; >irq : int; >status : char); > > Should this be rather split into device_irq_enable/disable and drop the > status paramter? What about using the I/O port scheme? That is, decide_intr_notify doesn't enable IRQ notifications, but instead just returns a handle (compare i386_io_perm_create) that is then passed to device_irq_enable to enable/disable IRQ notifications (compare i386_io_perm_modify). Does that make sense in this IRQ scenario? Grüße, Thomas pgpKNGJJPeDT8.pgp Description: PGP signature
Re: user-level drivers
Thomas Schwinge, le Mon 09 May 2011 11:15:15 +0200, a écrit : > > The patches however add a few > > kernel RPCs, which we should probably agree on first, at the minimum > > that their existence makes sense, so we can reserve slots in upstream > > gnumach. Basically, it's about allocating physically-contiguous memory > > for DMAs, and getting IRQ events: > > Of course, it doesn't matter at the moment, but are these for x86 only, > or architecture independent? Well, it does matter since that changes the allocation which we'd do. I believe that as it is proposed, it is architecture-agnostic: allocating a physically-contiguous area of memory for things like DMAs, and being notified of hardware requests. The vocabulary of the calls should be made arch-neutral of course. > Hmm, I guess we don't have anything that is better than using > vm_address_t for physical addresses? At least not in > include/mach/std_types.h, i386/include/mach/i386/vm_types.h. Should we? > (phys_address_t based on natural_t?) Maybe we should, indeed, else we can't do PAE. > At this time, would it make sense to make paddr inout (and/or vaddr, > too?) and add an additional ``anywhere : boolean_t'' parameter as > vm_allocate has? Or can't there be any need for such functionality? I was wondering too. I don't think it makes sense for paddr: either you do care, and then should simply use /dev/mem and whatever we implement behind (currently it's the mem driver), or you don't care. For vaddr, I was wondering. With Zheng Da's current implementation it's not trivial to add !anywhere support, but it could make sense indeed. > > The actual event: > > > > simpleroutine mach_notify_irq( > >notify : notify_port_t; > >name: int); > > I don't understand this ``name : int''. Isn't this rather a pointer to a > struct mach_irq_notification_t? It's actually the interrupt line number. > What about using the I/O port scheme? That is, decide_intr_notify > doesn't enable IRQ notifications, but instead just returns a handle > (compare i386_io_perm_create) that is then passed to device_irq_enable to > enable/disable IRQ notifications (compare i386_io_perm_modify). Does > that make sense in this IRQ scenario? It probably looks better, yes. Samuel
Re: user-level drivers
On Mon, May 09, 2011 at 12:17:51PM +0200, Samuel Thibault wrote: > > Hmm, I guess we don't have anything that is better than using > > vm_address_t for physical addresses? At least not in > > include/mach/std_types.h, i386/include/mach/i386/vm_types.h. Should we? > > (phys_address_t based on natural_t?) > > Maybe we should, indeed, else we can't do PAE. I'd suggest using natural_t (or unsigned long) too. But then, it can't be used to address >4 GiB physical memory. Consider expressing physical memory in page frame numbers. -- Richard Braun
Re: user-level drivers
Hallo! On Mon, 9 May 2011 12:17:51 +0200, Samuel Thibault wrote: > Thomas Schwinge, le Mon 09 May 2011 11:15:15 +0200, a écrit : > > > The patches however add a few > > > kernel RPCs, which we should probably agree on first, at the minimum > > > that their existence makes sense, so we can reserve slots in upstream > > > gnumach. Basically, it's about allocating physically-contiguous memory > > > for DMAs, and getting IRQ events: > > > > Of course, it doesn't matter at the moment, but are these for x86 only, > > or architecture independent? (I meant that given the non-usability of GNU Mach on other machines, it doesn't matter interface-wise whether we put them into mach.defs or mach_i386.defs.) Of course, making it independent of the architecture right now is better. > Well, it does matter since that changes the allocation which we'd do. I > believe that as it is proposed, it is architecture-agnostic: allocating > a physically-contiguous area of memory for things like DMAs, and being > notified of hardware requests. The vocabulary of the calls should be > made arch-neutral of course. Ack. > > Hmm, I guess we don't have anything that is better than using > > vm_address_t for physical addresses? At least not in > > include/mach/std_types.h, i386/include/mach/i386/vm_types.h. Should we? > > (phys_address_t based on natural_t?) > > Maybe we should, indeed, else we can't do PAE. But -- if this can return full PAE addresses -- then a natural_t isn't big enough either. As we have to be PAE-agnostic at this level (you can exchange a PAE with a non-PAE kernel, and expect your system still to work), we'd need something that works in either case -- in any cases where we mean to be ABI compatible, which for PAE va. non-PAE only is physical addresses. (Same for the Xen port, I guess?) While we're at this, we could also think about any issues with running a 32 bit user land on a 64 bit GNU Mach -- but at this kernel interface, that's already covered with PAE addresses, I think? > > At this time, would it make sense to make paddr inout (and/or vaddr, > > too?) and add an additional ``anywhere : boolean_t'' parameter as > > vm_allocate has? Or can't there be any need for such functionality? > > I was wondering too. I don't think it makes sense for paddr: either you > do care, and then should simply use /dev/mem and whatever we implement > behind (currently it's the mem driver), or you don't care. OK. > For vaddr, I was wondering. With Zheng Da's current implementation it's > not trivial to add !anywhere support, but it could make sense indeed. OK. We don't have to implement it (if we don't have a need for it at the moment), but we should provision for it in the RPC interface (and always have it fail with KERN_INVALID_ARGUMENT or whatever is appropriate). Grüße, Thomas pgpzwxt0UL0gt.pgp Description: PGP signature
Re: user-level drivers
Hallo! On Mon, 9 May 2011 13:19:22 +0200, Richard Braun wrote: > On Mon, May 09, 2011 at 12:17:51PM +0200, Samuel Thibault wrote: > > > Hmm, I guess we don't have anything that is better than using > > > vm_address_t for physical addresses? At least not in > > > include/mach/std_types.h, i386/include/mach/i386/vm_types.h. Should we? > > > (phys_address_t based on natural_t?) > > > > Maybe we should, indeed, else we can't do PAE. > > I'd suggest using natural_t (or unsigned long) too. But then, it can't > be used to address >4 GiB physical memory. Consider expressing physical > memory in page frame numbers. Good idea! But: what about differently sized frames (4 KiB/2 MiB/whatever amd64 allows)? (In case it'd make sense to support these at some point?) Or is this over-engineering already? Grüße, Thomas pgpTtOACGU65b.pgp Description: PGP signature
Re: user-level drivers
On Mon, May 09, 2011 at 01:27:32PM +0200, Thomas Schwinge wrote: > > I'd suggest using natural_t (or unsigned long) too. But then, it can't > > be used to address >4 GiB physical memory. Consider expressing physical > > memory in page frame numbers. > > Good idea! But: what about differently sized frames (4 KiB/2 > MiB/whatever amd64 allows)? (In case it'd make sense to support these at > some point?) Or is this over-engineering already? These are virtual frames. And in any case, they are multiple of the base page size. This interface is suitable for allocating large pages. It would just require the requested size to be a multiple of the large page size to indicate large pages are wanted. This "large page" size would be provided through a new macro sitting next to PAGE_SIZE. -- Richard Braun
Race problem in Mach/Hurd?
Hi, Continuing the struggle with the ghc and ruby build problems I stumbled into finding two kernel (signal) threads in addition to the main (user) thread. According to Neal on IRC there shouldn't be more than one kernel thread running. This could be due to some race condition (don't know yet where). Anyway, adding a print statement at eglibc-2.11.2/mach/msgserver.c resolved the hang in the configuration of ghc6-6.10.1 +dfsg1/libraries/random :-) For more info see http://pastebin.com/RcJs0Nht Single stepping in msgserver.c also triggered the console printout: task 5040ee18 deallocating an invalid port 340/xxx, most probably a bug. I think we are on the track to find where the cause of the build problems are.
Re: Race problem in Mach/Hurd?
Svante Signell, le Mon 09 May 2011 18:33:14 +0200, a écrit : > Anyway, adding a print statement at eglibc-2.11.2/mach/msgserver.c > resolved the hang in the configuration of ghc6-6.10.1 > +dfsg1/libraries/random :-) Uh! Did you try to let the remainder of the build complete? > Single stepping in msgserver.c also triggered the console printout: task > 5040ee18 deallocating an invalid port 340/xxx, most probably a bug. Note that you can make the kernel start the in-kernel debugger in that case. Simply set the mach_port_deallocate_debug variable to 1, or use nm on the "gnumach" binary to get its adress, e.g. 0x20001234, and use w 20001234 1 cont from the kernel debugger (use ctrl-alt-d to invoke it) to write a 1 there. Samuel
Re: Race problem in Mach/Hurd?
On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote: > Svante Signell, le Mon 09 May 2011 18:33:14 +0200, a écrit : > > Anyway, adding a print statement at eglibc-2.11.2/mach/msgserver.c > > resolved the hang in the configuration of ghc6-6.10.1 > > +dfsg1/libraries/random :-) > > Uh! Did you try to let the remainder of the build complete? No, I had a print statement writing too much so the build hang so I had to reboot. Now I just print a dot so I can try again. > > Single stepping in msgserver.c also triggered the console printout: task > > 5040ee18 deallocating an invalid port 340/xxx, most probably a bug. > > Note that you can make the kernel start the in-kernel debugger in that > case. Simply set the mach_port_deallocate_debug variable to 1, or use nm > on the "gnumach" binary to get its adress, e.g. 0x20001234, and use > > w 20001234 1 > cont > > from the kernel debugger (use ctrl-alt-d to invoke it) to write a 1 > there. I'll try this later. Another new thing to learn.
Re: [scdbac...@gmx.net: Interface for SCSI transactions ?]
Hi, Thanks to all for your patience with my newbieness. me: > > So it looks as if we have to stop here until a better skilled person > > appears who is interested in enabling burner drive operation. Samuel Thibault: > I'll let it to anybody who has time for this. After pondering and code reading about your proposal via device_get_status() without new RPC, it appears viable enough for a try. A potential problem is that scsi_ioctl_send_command() is restricted to transfer MAX_BUF = PAGE_SIZE payload bytes. I could not spot the definition of PAGE_SIZE yet. I'd need at least 32 kiB payload. Better for Blu-ray would be 64 kiB. (Proper alignment matters. Older cdrecord sends 62 kB per call and has problems with many DVD and Blu-ray burners.) In scsi_ioctl.c:scsi_ioctl_send_command i read: * We do not transfer more than MAX_BUF with this interface. * If the user needs to transfer more data than this, they * should use scsi_generics instead. I am unable to determine whether this limit also applies to scsi_do_cmd() in hurd/gnumach/linux/src/drivers/scsi/scsi.c which seems to do the transaction work. Is there a limit for the number of integers with device_get_status() ? (I'd need at least 32 kiB payload plus about 1 kB of other stuff. Better would be 65 kiB.) -antrik- : > I'm certainly willing to mentor > you on the Hurd-specific aspects as well as I can; but I won't promise > anything more... A sketch how to set up an own Hurd development with access to a real CD drive and remote login via real Ethernet would be very welcome. Just enough detail to estimate the effort. An interested user who really wants to burn CD, DVD, or BD, would be an extra motivation. :)) antrik: > I'm sure you do have the necessary skills -- the question is rather > whether you are willing to spend considerable time digging into Hurd > internals :-) There would be quite some learning involved. I am a userland programmer who stumbled into libburn and its SCSI interface only by accident. Meanwhile this accident evolved and i have a test machine with FreeBSD, Solaris, and Debian 5. It has a single disk where i could use partition 2 with 50 GB for a real Hurd. But from lurking here i got the impression that you all use it on virtual machines, rather than on real amd64 + SATA + USB + Ethernet. Being nearly as few of a sysadmin as i am device driver developer, i would first have to learn about running VM on Linux. Then somebody or some documentation would have to drag me through learning the development cycle of Hurd. (Plus the overdue housework to upgrade from Debian 5 to 6 which would affect my GRUB-legacy boot contraption that lives in Debian 5.) me: > > I am open for cooperation and also for doing some slave work. antrik: > Not sure what you mean by "slave work"? The slave work would be to implement structures and methods on both sides of the RPC interface. I could contribute SCSI knowledge (command set, not hardware) and believe to have identified existing code on the "kernel" side of RPC which already performs the needed SCSI transaction. Meanwhile i believe to understand Samuel's proposal for a quick hack. If PAGE_SIZE is not a show stopper, then one could attach scsi_ioctl(SCSI_IOCTL_SEND_COMMAND, ...) from gnumach/linux/src/drivers/scsi/scsi_ioctl.c to the kernel side of device_get_status(). I understand from the comments in scsi_ioctl.c that this is a predecessor of the Linux SG_IO interface (Linux kernel >= 2.4). I still have to explore how to beef up the userland side of device_get_status(). And at some point i would have to get from theory to practice. Have a nice day :)
Re: Account request
Hallo Steven! On Mon, 9 May 2011 12:59:27 -0400, seth seth wrote: > Thanks for creating the account but unable to login, is > flubber.bddebian.comdown? His whole network is unreachable at the moment. I've already informed Barry; he's going to have a look. Grüße, Thomas pgpzYuP8LdDH5.pgp Description: PGP signature
Re: Race problem in Mach/Hurd?
On Mon, 2011-05-09 at 18:49 +0200, Svante Signell wrote: > On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote: > > Svante Signell, le Mon 09 May 2011 18:33:14 +0200, a écrit : > > > Anyway, adding a print statement at eglibc-2.11.2/mach/msgserver.c > > > resolved the hang in the configuration of ghc6-6.10.1 > > > +dfsg1/libraries/random :-) > > > > Uh! Did you try to let the remainder of the build complete? > > No, I had a print statement writing too much so the build hang so I had > to reboot. Now I just print a dot so I can try again. The build continues until the following message is printed: make: hurdsig.c:804: _hurd_internal_post_signal: Unexpected error: (ipc/rcv) msg too large. Maybe it's due to the print statements I still have in the custom built libc. I'll recompile so nothing is printed to stderr (not clobbering the normal output)
Re: Race problem in Mach/Hurd?
On Mon, 2011-05-09 at 19:08 +0200, Svante Signell wrote: > On Mon, 2011-05-09 at 18:49 +0200, Svante Signell wrote: > > On Mon, 2011-05-09 at 18:43 +0200, Samuel Thibault wrote: > > > Svante Signell, le Mon 09 May 2011 18:33:14 +0200, a écrit : > > > > Anyway, adding a print statement at eglibc-2.11.2/mach/msgserver.c > > > > resolved the hang in the configuration of ghc6-6.10.1 > > > > +dfsg1/libraries/random :-) > > > > > > Uh! Did you try to let the remainder of the build complete? > > > > No, I had a print statement writing too much so the build hang so I had > > to reboot. Now I just print a dot so I can try again. > > The build continues until the following message is printed: > make: hurdsig.c:804: _hurd_internal_post_signal: Unexpected error: > (ipc/rcv) msg too large. > > Maybe it's due to the print statements I still have in the custom built > libc. I'll recompile so nothing is printed to stderr (not clobbering the > normal output) At least the whole compiler stage 1 did complete. I've made so many changes so I don't know why configuring stage2 build hangs. Trying to build from scratch with the custom libc. BTW: I'm still seeing the bad file descriptor errors in eglibc-2.11.2/sysdeps/mach/hurd/read.c since I have kept a print statement there. And these are the remaining errors when compiling ruby. Multiple bugs?
Re: emacs23.3 issues and hurd signals
Svante Signell, le Sun 08 May 2011 11:12:25 +0200, a écrit : > On Sat, 2011-05-07 at 01:54 +0200, Samuel Thibault wrote: > > Svante Signell, le Thu 05 May 2011 19:11:10 +0200, a écrit : > > > Backtraces are attached! > > > > Could you also run disassemble, so we get the corresponding assembly > > code? > > > > Also, maybe the issue is in some thread other than main, so > > > > thread apply all backtrace > > thread apply all disassemble > > > > would help. > > Ok, the requested backtraces and disassembly is attached. Please let me > know if the main thread disassembly is too big for the list (35k). The > backtrace is from emacs23.3 compiled with gcc-4.6 -O0. Any other > compiler version or optimization level needed? The simplest backtrace to analyze would probably be in the "illegal instruction" case. Also, thread apply all info register would be helpful too :) Samuel
Re: user-level drivers
Richard Braun, le Mon 09 May 2011 10:55:36 +0200, a écrit : > This RPC lacks a few additional constraints like boundaries, alignment > and maybe phase. What do you mean by "phase"? Samuel
Re: user-level drivers
Richard Braun, le Mon 09 May 2011 13:33:37 +0200, a écrit : > On Mon, May 09, 2011 at 01:27:32PM +0200, Thomas Schwinge wrote: > > > I'd suggest using natural_t (or unsigned long) too. But then, it can't > > > be used to address >4 GiB physical memory. Consider expressing physical > > > memory in page frame numbers. > > > > Good idea! But: what about differently sized frames (4 KiB/2 > > MiB/whatever amd64 allows)? (In case it'd make sense to support these at > > some point?) Or is this over-engineering already? > > These are virtual frames. There are archs which have varying page size. I'd rather avoid introducing the page size, can't mig cope with 64bit values on 32bit archs? Samuel
Re: Account request
On 5/9/2011 1:09 PM, Thomas Schwinge wrote: > Hallo Steven! > > On Mon, 9 May 2011 12:59:27 -0400, seth seth wrote: >> Thanks for creating the account but unable to login, is >> flubber.bddebian.comdown? > > His whole network is unreachable at the moment. I've already informed > Barry; he's going to have a look. > > > Grüße, > Thomas Should be back up now. Please let me know if there is still an issue. Thanks, Barry
Re: emacs23.3 issues and hurd signals
On Tue, 2011-05-10 at 01:54 +0200, Samuel Thibault wrote: > The simplest backtrace to analyze would probably be in the "illegal > instruction" case. Also, > > thread apply all info register > > would be helpful too :) Pasted in below, good luck! Thread 5 (Thread 21895.5): eax0x10004005 268451845 ecx0x17fdc5425156692 edx0x1000 4096 ebx0x126fff419333108 esp0x17fdec80x17fdec8 ebp0x17fdefc0x17fdefc esi0x77 119 edi0x0 0 eip0x10fef4c0x10fef4c eflags 0x202[ IF ] cs 0x17 23 ss 0x1f 31 ds 0x1f 31 es 0x1f 31 fs 0x1f 31 gs 0x4b 75 Thread 4 (Thread 21895.4): eax0x3 3 ecx0xfc00 -1024 edx0xfc00 -1024 ebx0x -1 esp0x15f95100x15f9510 ebp0x15f95680x15f9568 esi0xfb 251 edi0x9 9 eip0x81505290x8150529 eflags 0x10286 [ PF SF IF RF ] cs 0x17 23 ss 0x1f 31 ds 0x1f 31 es 0x1f 31 fs 0x1f 31 gs 0x4b 75
