On Tue, Sep 22, 2020 at 01:28:42PM +0200, Richard Braun wrote:
> On Fri, Aug 28, 2020 at 06:39:29PM +0200, Samuel Thibault wrote:
> > One way to avoid the bug is to use the e1000 hardware network type. I
> > guess the rtl8139 driver that we ship in netdde has a bug in its irq
>
st an optimization,
so it should be completely safe to just comment it out on systems where
the macro doesn't exist (assuming it's a macro).
--
Richard Braun
x27;t looked at the work, but if Samuel merged it, I trust it's
good. Thanks :).
--
Richard Braun
probably transmitted in clear.
>
> Would it be possible to fix that?
On vacation right now, but I'll get to it eventually.
--
Richard Braun
s changing all callers to not assume that allocated
memory can always be directly mapped, in particular some kvtophys calls.
--
Richard Braun
[1]
https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/vm/vm_resident.c?id=4dbaa718038fadc51d9b95d2383868a229d91457#n776
On Wed, Aug 25, 2021 at 04:23:23PM +0200, Samuel Thibault wrote:
> Richard Braun, le mer. 25 août 2021 15:59:12 +0200, a ecrit:
> > I can't recall exactly, but that's why we write comments, right ?
> > See [1].
> >
> > Fixing this requires changing all
On Tue, Aug 17, 2021 at 10:29:42AM +0200, Richard Braun wrote:
> On Mon, Aug 16, 2021 at 11:23:23PM +0200, Denis 'GNUtoo' Carikli wrote:
> > While it's relatively easy to create an account on the Hurd wiki[1] and
> > to edit it, everything is in http.
> >
>
I'm happy to report it's been a long time since I've seen this indeed.
Thanks !
--
Richard Braun
---
libps/procstat.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libps/procstat.c b/libps/procstat.c
index d0423410..131d3a4b 100644
--- a/libps/procstat.c
+++ b/libps/procstat.c
@@ -1097,6 +1097,7 @@ _proc_stat_free (ps)
0, &ps->task_events_info_buf, char);
MFREEMEM (PSTAT_
you from inspecting the
kernel (and more specifically, the IDT) to determine what interrupts 7
and 11 are ?
--
Richard Braun
could be light, and I might have missed them. Does anyone know if
the Hurd servers actually use thread migration ?
--
Richard Braun
like to propose the following update. Everyone is invited to
> rephrase it :)
Hello,
Now that was a long time ago. I don't have a network access at home for
now, and I'm quite busy at work, but give me some time to get reminded of
what the code actually does and I'll comment on your changes soon.
Thanks for noticing this.
--
Richard Braun
"
sound more appropriate. But this is just a detail though.
3/
You should probably describe that, when a packet is received by a
listener, the flags are *either* NETF_IN or NETF_OUT, and not a
combination of both, even though common sense would make it obvious.
--
Richard Braun
reeing list elements in two steps
is also a technique commonly used to reduce contention.
--
Richard Braun
nd in
the "child" translator as long as it runs, as a reference to the
translator managing .. (that is, ports[INIT_PORT_CWDIR]) ? In addition,
is this a mach port leak or a libports leak ?
--
Richard Braun
located: once the child translator terminates,
all its rights on the port are destroyed, which generates a no-sender
notification, on which the receive port is destroyed. I hope the child
translator doesn't copy this right to other tasks, in which case we
would have to track where and how references are passed.
--
Richard Braun
quot; 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
> (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
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
e. So
using 64 bits seems reasonable. Mig should have no problem with 64 bits
values.
--
Richard Braun
ing the right alignment and size
is enough.
--
Richard Braun
ernel
> thread running. This could be due to some race condition (don't know yet
> where).
What makes you think there are two signal threads ?
--
Richard Braun
On Tue, May 10, 2011 at 10:53:00AM +0200, Svante Signell wrote:
> On Tue, 2011-05-10 at 10:11 +0200, Richard Braun wrote:
> > What makes you think there are two signal threads ?
>
> Did you look at the pasted output?
Are you serious asking that ?
> I would call threads 5 and
ply be that
timer_create() is called with SIGEV_THREAD.
The invalid memory address is likely garbage at the top of the stack.
I wouldn't worry about it.
--
Richard Braun
On Tue, May 10, 2011 at 11:18:21AM +0200, Richard Braun wrote:
> I'll check how glibc deals with POSIX timers. It could simply be that
> timer_create() is called with SIGEV_THREAD.
>
> The invalid memory address is likely garbage at the top of the stack.
> I wouldn't wor
. I guess it may
be the same for other people as well.
--
Richard Braun
Hello,
I've noticed something strange with the shell recently :
$ vminfo $$ | wc -l
1038
Why would bash use so many map entries ?
--
Richard Braun
they're mostly abandonned. Concerning GNU Mach, the current priority
is userspace drivers through DDE (which makes real time hardware
accesses even harder), and there are no plans to make it real time in
the near future.
--
Richard Braun
[1] http://www.rtmach.org/index-e.html
> explained by this either I guess...)
>
> Either way, I have no idea how to go about narrowing down the problem
> :-(
Here is a simple suggestion: try to measure the depth of the shadow
object chains.
--
Richard Braun
lear, simple,
centralized explanation).
--
Richard Braun
's really simple enough.
--
Richard Braun
7;t
> find any reason in our current code.
Looks fine, yes. I believe the reason was mainly historical anyway.
--
Richard Braun
Hello,
What are the requirements concerning additions (specifically, new files)
in GNU Mach ? In particular, what coding style should be used for them ?
--
Richard Braun
or applications which
know they'll modify the received buffer, or frequently transfer small
amounts of data. The same could be done for vm_read/vm_write of course.
--
Richard Braun
e interested in getting statistics from a kernel using the slab
allocator, a slabinfo [1] tool is publically available (although it will
take some time to get it in the Hurd, because of the mach_debug
interface not being exported, I'll open discussion on that soon).
--
Richard Braun
[1] http://git.sceen.net/rbraun/slabinfo.git/
se a signal back (IIRC Xorg does this). That would implement the
> "make father wait" in a portable way.
How about blocking signals until the child is actually able to handle
SIGTERM correctly ? POSIX clearly states signal masks are inherited on
forks. AIUI, this case doesn't nee
enough positive feedbacks are obtained, so feel free to test
and report your comments.
Thanks.
--
Richard Braun
ear about it.
Enjoy.
--
Richard Braun
On Sat, Jan 28, 2012 at 08:56:29PM +0100, Richard Braun wrote:
> The Debian packages are available at my brand new repository. Add these
> to your sources.list file (ftp:// access should also work) :
> deb http://ftp.sceen.net/debian-hurd experimental/
> deb-src http://ftp.sceen.net
On Sat, Jan 28, 2012 at 08:56:29PM +0100, Richard Braun wrote:
> I'm currently working on getting libpcap to a decent state on the Hurd.
> The Debian packages are available at my brand new repository. Add these
> to your sources.list file (ftp:// access should also work
I'm not sure Xnu "chose" anything
there, as port names were early intended to be natural_t (because of
the optimization described above).
--
Richard Braun
On Mon, Apr 02, 2012 at 12:35:25PM +0200, Samuel Thibault wrote:
> Richard Braun, le Mon 02 Apr 2012 12:03:34 +0200, a écrit :
> > Kernel port names are addresses of their target IPC port object.
>
> Inside the kernel, yes. In the userland processes, no. That's the
> di
On Mon, Apr 02, 2012 at 01:57:31PM +0200, Samuel Thibault wrote:
> Richard Braun, le Mon 02 Apr 2012 13:46:08 +0200, a écrit :
> > How do they convert names from/to pointers ? Regular IPC space lookups ?
>
> Well, yes, just like GNU Mach does, in ipc_kmsg_copyin_header etc.
So
tion with segmentation and the 4GiB split. What is
the layout you expect for the kernel space ? First 4 GiB user then
kernel ? And you thought of segmentation to implicitely shift
addresses ? IMHO, changing GNU Mach to cleanly convert port names where
needed remains the sane choice.
--
Richard Braun
g. port sets, 64-bits). You may be thinking of converting
user names (32-bits) to kernel names (64-bits), then kernel names to IPC
objects. Am I right ?
--
Richard Braun
at's what I'm suggesting from the beginning. That needs two differents
> types (64bit mach_port_t and 32bit mach_port_name_t), where there is
> currently just one (vm_offset_t mach_port_t).
Then I don't see why you want two different types. There would be one
32-bits mach_port_t, and no mach_port_name_t.
--
Richard Braun
urt much and makes sense to use
a 32-bit type for port names, whatever the word size.
--
Richard Braun
7;t think it's needed, no. Again, make it easy to implement the
POSIX call. That's plenty for a first attempt.
--
Richard Braun
mostly ignore that readahead policy can be changed (keep it
in mind to isolate its implementation, but adding a default policy only
would still do). The vm_advise call should be added later, when actually
allowing applications to change the policy.
--
Richard Braun
Because of heavy map entry fragmentation and a poor map entry merging
implementation, the kernel can sometimes need thousands of map entries
to describe the address space of a task (most often a pager). This
change introduces a red-black tree in the VM maps with the purpose of
speeding up entry loo
Because of heavy map entry fragmentation and a poor map entry merging
implementation, the kernel can sometimes need thousands of map entries
to describe the address space of a task (most often a pager). This
change introduces a red-black tree in the VM maps with the purpose of
speeding up entry loo
tty
> you had.
On darnassus, this bug was seen faster when syslogd was enabled.
--
Richard Braun
On Sun, Jun 17, 2012 at 02:58:06PM -0700, Thomas Thomas wrote:
> PS - Does anyone use UFS?
Probably not.
--
Richard Braun
experience with
this part of the Hurd would take a look, it would be appreciated.
--
Richard Braun
[1] http://lists.gnu.org/archive/html/bug-hurd/2010-03/msg00127.html
[2] http://lists.gnu.org/archive/html/bug-hurd/2010-04/msg00012.html
much more content and history have showed it's
perfectly sane to keep that much in one place, and it simplifies keeping
the tightly coupled modules of the Hurd in sync.
--
Richard Braun
* ext2fs/inode.c (diskfs_node_iterate): allocate the temporary node
table from the heap instead of the stack.
Signed-off-by: Richard Braun
---
ext2fs/inode.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/ext2fs/inode.c b/ext2fs/inode.c
index f25cc1f..2da8a95
On Tue, Jul 03, 2012 at 09:13:36PM -0300, Samuel Thibault wrote:
> Richard Braun, le Tue 03 Jul 2012 23:13:26 +0200, a écrit :
> > * ext2fs/inode.c (diskfs_node_iterate): allocate the temporary node
> > table from the heap instead of the stack.
>
> That can be quite a lot
On Wed, Jul 04, 2012 at 08:29:13AM +0200, Thomas Schwinge wrote:
> On Tue, 3 Jul 2012 21:19:12 +0200, Richard Braun wrote:
> > Unless it's very easy to use submodules, we should use one repository.
> > Other projects with much more content and history have showed it's
&
On Wed, Jul 04, 2012 at 07:58:13AM -0300, Samuel Thibault wrote:
> Richard Braun, le Wed 04 Jul 2012 08:22:13 +0200, a écrit :
> > It's also quite a lot of heap too, and every 5 seconds. We should
> > consider increasing the interval between global syncs to reduce th
Hello,
Following our discussions on IRC, the weekly meetings will be reinstated
during the Google summer of code, to better follow the progress of the
students (although other subjects are of course welcome). The meeting is
scheduled on Thurdsay, 19:00 UTC.
--
Richard Braun
This patch lets the kernel unconditionnally cache non empty unreferenced
objects instead of using a fixed arbitrary limit. As the pageout daemon
evicts pages, it collects cached objects that have become empty. The
effective result is a graceful adjustment of the number of objects
related to memory
On Mon, Jul 09, 2012 at 04:44:57PM +0200, Richard Braun wrote:
> Note that you need up-to-date versions of both GNU Mach [1] and the
> Hurd [2] to test this patch, as it needs important bug fixes to avoid
> file system crashes and kernel panics.
Debian packages with the patch and the req
On Tue, Jul 10, 2012 at 03:15:00AM +0200, Samuel Thibault wrote:
> Richard Braun, le Tue 10 Jul 2012 03:03:09 +0200, a écrit :
> > Debian packages with the patch and the required bug fixes are available
> > at my repository :
>
> I guess they are all already in upstream git
On Tue, Jul 10, 2012 at 08:24:30AM +0200, Richard Braun wrote:
> On Tue, Jul 10, 2012 at 03:15:00AM +0200, Samuel Thibault wrote:
> > I'm currently uploading new hurd, gnumach & netdde packages.
>
> The bug fixes have been committed, but not the VM cache patch, which is
On Thu, Jul 12, 2012 at 04:03:55PM +0200, Thomas Schwinge wrote:
> I have now promoted this branch from jkoenig/master to master -- it is
> the procfs variant that we've been using ever since, and the two
> different branches recently confused Richard.
That was quick, thanks.
--
Richard Braun
If no major objection is raised (particularly about the new Mig
routine), I'll commit this patch in a few days.
The decision to add the call to the mach4 interface stems from
pragmatism. It doesn't break existing compatibility, and it doesn't add
the burden of a new interface.
---
include/mach/ma
On Tue, Jul 10, 2012 at 07:26:54PM +0200, Richard Braun wrote:
> An up-to-date gnumach package including the patch is now available.
Patched versions of the gnumach and hurd packages are available at my
repository. They include the page cache accounting and policy change
patches (gnumach),
ll itself, e.g. vm_cache_statistics1 etc.. ?
--
Richard Braun
lready.
Thanks for this report. The results of vmstat and slabinfo (vm_object,
thread and ipc_port lines) are what I'm mostly interested in. I suspect
there are quite a lot of them, and the performance regression probably
comes from the scalability issues previously described.
--
Richard Braun
On Sat, Jul 14, 2012 at 05:06:37PM +0200, Richard Braun wrote:
> If no major objection is raised (particularly about the new Mig
> routine), I'll commit this patch in a few days.
As I intend to continue working on the page cache, and because the
policy patch alone can't be incl
* rootdir.c: Add #include .
(rootdir_gc_meminfo): Call vm_cache_statistics() and report the result.
---
rootdir.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/rootdir.c b/rootdir.c
index 1fa71b0..c24585e 100644
--- a/rootdir.c
+++ b/rootdir.c
@@ -20,6 +20,7 @@
#in
t your progress.
--
Richard Braun
Hello,
In the hurd/io.defs file, which defines the Hurd I/O interface, the
io_select call includes a timeout. However, none of the libraries and
servers implementing this call receive it. What makes this argument
"disappear" during stub code generation ?
--
Richard Braun
#x27;ve been looking for the raw string
"waittime" in the MiG code, whereas the parser seems to be case
insensitive... Thanks for your reply.
--
Richard Braun
_cond_wait and
pthread_cond_timedwait functions, considering how related they are ?
--
Richard Braun
new
call when appropriate.
THanks.
--
Richard Braun
[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=79358
On Wed, Jul 25, 2012 at 06:34:02PM +0200, Richard Braun wrote:
> For now, this branch only adds support for server-side timeouts. The
> select implementation in glibc still needs to be changed to use the new
> call when appropriate.
The change I want to apply means io_select call
se there
isn't any in the cthreads package. You should be able to replace it with
pthread_cancel without further effort.
--
Richard Braun
how to mark a thread as being
> >cancelled. The hurd_thread_cancel function merely exists because there
> >isn't any in the cthreads package. You should be able to replace it with
> >pthread_cancel without further effort.
>
> >--
> >Richard Braun
>
flocal did.
> That would also handle hurd_check_cancel.
Why not.
--
Richard Braun
ers.
The problem with that is, if a Hurd server internally calls a function
that is a cancellation point, the calling thread will automatically exit
before having a chance to reply to the client. A Hurd-specific type
should allow the safe use of more standard functions.
--
Richard Braun
function in
the cthreads library. It prove more difficult than I initially expected
precisely because of the issues around the condition queue (they also
apply to pthread_mutex_timedlock). In short, this is a bug. You can take
a look at my work directly on the Hurd repository [1].
--
Richard Braun
a name that's descriptive of what it means,
> rather than what programs are expected to use it. For example,
> PTHREAD_CANCEL_POLLED.
Could it hurt portability (not that I know of any other system using
glibc that uses such tricks, but still) ?
--
Richard Braun
h the
> convention in NPTL for extensions, it should be PTHREAD_CANCEL_POLLED_NP.
> (The "_NP" suffix indicates it's a non-POSIX feature.)
Nothing particular in mind, It's just that I initially saw this type as
being Hurd-specific, but there is no reason to tie it to the Hurd.
--
Richard Braun
On Wed, Jul 25, 2012 at 06:34:02PM +0200, Richard Braun wrote:
> A while ago [1], issues were found with the use of select along with
> a timeout. In an attempt to fix those, I have created a branch in the
> Hurd repository which adds a new call to the io interface,
> io_select_
ead soon as they are perfectly
relevant, since the algorithms are very similar (if not exactly the
same).
--
Richard Braun
On Fri, Aug 03, 2012 at 12:20:09PM -0700, Thomas DiModica wrote:
> I was thinking about what Richard Braun said about removing
> hurd_thread_cancel.
> Attached is an exploration into implementing PTHREAD_CANCEL_HURD as a
> cancellation state extension. It compiles, but I haven
ropen at release time never seen at creation
time ?
--
Richard Braun
On Fri, Aug 10, 2012 at 12:49:05AM +0200, Richard Braun wrote:
> The GDB traced I've obtained [1] shows a couple of matching
> create/destroy hooks, but the first (create) call, which trivfs control
> matches ptyctl (po->cntl == ptyctl), is never destroyed. At the same
> time,
What would you recommend we name the matching pthread_cond_wait-like
function ? Something like pthread_cond_poll_np ?
--
Richard Braun
On Sat, Aug 11, 2012 at 07:42:27PM +0200, Richard Braun wrote:
> On Fri, Aug 03, 2012 at 01:44:54PM -0700, Roland McGrath wrote:
> > I can't really imagine what issue you have in mind. To fit with the
> > convention in NPTL for extensions, it should be PTHREAD_CANCEL_POLL
ot;
here means the stack size is the default. Why not check against the real
stack size as stored in the __pthread structure ?
In addition, here you only mention the recylcing problem, not the
threadvar alignment problem. Or is there no such problem ?
--
Richard Braun
y created by _hurdsig_init, but only if the proc
server exists (see hurd/hurdinit.c). Obviously, when used as a root file
system, this isn't the case.
What prevents _hurdsig_init from being called unconditionally and
earlier ?
--
Richard Braun
On Wed, Aug 15, 2012 at 11:24:20AM +0200, Richard Braun wrote:
> What prevents _hurdsig_init from being called unconditionally and
> earlier ?
In the meantime, I merely made sigstate_is_global_rcv check that
_hurd_global_sigstate isn't NULL. Now I have a subhurd completely
populated
ed faithful to
the ctrheads version, and your explanations makes sense. Second, ufs
is planned to be phased out as noone uses it.
--
Richard Braun
On Wed, Aug 15, 2012 at 03:03:55PM +0200, Samuel Thibault wrote:
> The alignment issue is for threadvars: as long as we have them, we
> need the stack to be aligned, and some constant size. Fortunately,
> threadvars are to be dropped, but it's still not complete yet.
That's also the idea I got fr
ype is set. This call in the
cleanup callback is meant to restore the type on entry in case no
cancellation occurred.
--
Richard Braun
On Thu, Aug 16, 2012 at 11:48:35AM +0200, Richard Braun wrote:
> On Wed, Aug 15, 2012 at 05:47:47PM -0700, Thomas DiModica wrote:
> > My understanding is that pthread_cond_wait is a cancellation point.
> > It achieves this by entering asynchronous cancellation mode before block
libports/manage-multithread.c: Add #include
(ports_manage_port_operations_multithread): Make threads depress
their priority on startup.
---
libports/manage-multithread.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libports/manage-multithread.c b/libports/manage-multithread.
rd servers
can be used until a redesign allows really fixing this issue.
Thanks.
--
Richard Braun
1 - 100 of 595 matches
Mail list logo
