On Fri, Mar 24, 2006 at 01:37:54AM +0100, Blaisorblade wrote:
> Yep, it seems it looks good. But 1 bug still and two suggestions.
> See also attached patch (it misses one of the suggestions because it's late
> and I'm going to sleep).
I merged that patch.
> If possible (there should be such arra
On Thursday 23 March 2006 19:45, Jeff Dike wrote:
> On Tue, Mar 21, 2006 at 02:21:40AM +0100, Blaisorblade wrote:
> > However, while I overlooked this, you overlooked what I did:
> > *) you must also move the setting of write_sigio_fds and sigio_private
> > above, or we'll get the same problem agai
On Thu, Mar 23, 2006 at 06:23:11PM -0300, Werner Almesberger wrote:
> Ah, mysteries of the world, easily explained :-)
:-)
> Do you plan to submit this for 2.6.16.x ?
Haven't thought about that yet. It would certainly be a candidate.
Jeff
Jeff Dike wrote:
> Nope, it's just later in my patchset than one which moves the file.
Ah, mysteries of the world, easily explained :-)
Do you plan to submit this for 2.6.16.x ?
- Werner
--
_
/ Werner Almesberger, Bueno
On Thu, Mar 23, 2006 at 04:05:33PM -0300, Werner Almesberger wrote:
> Hmm, is this a link ?
>
> % find linux-2.6.15.5/arch/um -name sigio.c
> %
Nope, it's just later in my patchset than one which moves the file.
> The patch applies cleanly to arch/um/kernel/sigio_user.c of 2.6.16,
> though, and
Jeff Dike wrote:
> Index: linux-2.6.15/arch/um/os-Linux/sigio.c
Hmm, is this a link ?
% find linux-2.6.15.5/arch/um -name sigio.c
%
The patch applies cleanly to arch/um/kernel/sigio_user.c of 2.6.16,
though, and indeed seems to solve the problem.
Thanks,
- Werner
--
On Tue, Mar 21, 2006 at 02:21:40AM +0100, Blaisorblade wrote:
> However, while I overlooked this, you overlooked what I did:
> *) you must also move the setting of write_sigio_fds and sigio_private above,
> or we'll get the same problem again in different places of
> write_sigio_thread.
Fixed.
>
On Tuesday 21 March 2006 02:00, Jeff Dike wrote:
> On Fri, Mar 17, 2006 at 08:36:58PM +0100, Blaisorblade wrote:
> > 2) write_sigio_thread should do a "down" on a semaphore/mutex and the
> > first update_thread should "up" it. As usually, this semaphore would be
> > indeed implemented as a pipe.
>
On Fri, Mar 17, 2006 at 08:36:58PM +0100, Blaisorblade wrote:
> 2) write_sigio_thread should do a "down" on a semaphore/mutex and the first
> update_thread should "up" it. As usually, this semaphore would be indeed
> implemented as a pipe.
Is there anything wrong with this:
Index: linux-2.6.15/
Blaisorblade wrote:
> 2) write_sigio_thread should do a "down" on a semaphore/mutex and the first
> update_thread should "up" it. As usually, this semaphore would be indeed
> implemented as a pipe.
Be the way, in case a proper fix is too involved for 2.6.16.x,
here's a quick and dirty work-aroun
Blaisorblade wrote:
> however usleep(3) exists since 4.3 BSD so this is a
> bit unlikely;
Oh, there must be a million of passably valid reasons why someone
may still do it this way, e.g.,
- because they don't know of the more suitable function
- because they don't trust the more suitable functi
On Friday 17 March 2006 22:27, Werner Almesberger wrote:
> Blaisorblade wrote:
> > 1) I'll try to fix poll(2) to return -EINVAL. Dunno whether anyone will
> > say "no, the app is stupid, it deserves no error", but hope not (with
> > "try" I refer to this). Attached patch should do this.
>
> I think
Blaisorblade wrote:
> 1) I'll try to fix poll(2) to return -EINVAL. Dunno whether anyone will say
> "no, the app is stupid, it deserves no error", but hope not (with "try" I
> refer to this). Attached patch should do this.
I think the behaviour of "poll" with nfds = 0 is correct as it is.
At lea
On Thursday 16 March 2006 15:22, Werner Almesberger wrote:
> Jeff Dike wrote:
> > Having said that,
> > if you can get a stack from the hang, it might turn out to be an easily
> > diagnosed and fixed bug.
>
> Seems that arch/um/kernel/sigio_user.c:write_sigio_thread begins
> its poll before there a
Jeff Dike wrote:
> Having said that,
> if you can get a stack from the hang, it might turn out to be an easily
> diagnosed and fixed bug.
Seems that arch/um/kernel/sigio_user.c:write_sigio_thread begins
its poll before there are any fds in current_poll, so update_thread
caused by a add_sigio_fd sh
On Tuesday 14 March 2006 3:22 pm, Jeff Dike wrote:
> On Sat, Mar 11, 2006 at 01:01:41PM -0500, Rob Landley wrote:
> > On linux-2.6.16-rc5 I'm occasionally getting a hang starting up (with
> > rootfstype=hostfs), right after the initializing VFS line.
>
> I'm in the process of beating on the newer e
On Sat, Mar 11, 2006 at 01:01:41PM -0500, Rob Landley wrote:
> On linux-2.6.16-rc5 I'm occasionally getting a hang starting up (with
> rootfstype=hostfs), right after the initializing VFS line.
I'm in the process of beating on the newer externfs-based hostfs and humfs,
so I'm not too concerned
On Saturday 11 March 2006 19:01, Rob Landley wrote:
> On linux-2.6.16-rc5 I'm occasionally getting a hang starting up (with
> rootfstype=hostfs), right after the initializing VFS line. This time when
> I killed it, I got the following error (repeated twice):
>
> remove_umid_dir - actually_do_remov
On linux-2.6.16-rc5 I'm occasionally getting a hang starting up (with
rootfstype=hostfs), right after the initializing VFS line. This time when I
killed it, I got the following error (repeated twice):
remove_umid_dir - actually_do_remove failed with err = -2
I'm guessing that's where it's hang
19 matches
Mail list logo
