lkml.org 
[lkml]   [1999]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 2.2.0-final
Date: 22 Jan 1999 23:02:23 +0100


Dans mail.linux.kernel, Thomas Quinot écrit :

>>OBTW: same problem with modutils 2.1.121: while boot scripts try
>>to fsck the IDE disk (which is modularized), the module gets
>>inserted, but it looks like fsck gets back control /before/ the
>>module has had time to initialize, and so gets something like
>>a -ENODEV.

>> Further investigation revealed that the culprit is the vfork() change
>> introduced in pre9. In both cases (modprobe and loadkeys), the C
>> library tried to sys_vfork() upon a call to system() or popen().
>> In pre8 and earlier kernels, this resulted in -ENOSYS and libc performed
>> a fork() instead (__libc_system calls __vfork which is defined as
[Snip code]
>>). (This is GLibc 2.0.110. The problem will also be reported to the
>>libc-alpha mailing list).

>>In pre9, the new vfork system call is performed, and this results
>>(for some reasons that I have yet to investigate) in a seg fault
>>in the calling process. Backing out the change to entry.S so that
>>syscall(__NR_vfork) returns ENOSYS resolves the symptom.
Also Glibc 2.0.110, system hung while booting trying to load lpd. lp
stuff as module. Also failed to load vfat and ps mouse.
I tried going to glibc 2.0.111, but linuxthreads-2.0.111 would not
compile.
pre8 boots fine.
Backing out the change to entry.S works here.
Does vfork count as a brown paper bag?
--
Garst

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.027 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site