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/