Messages in this thread | | | Date | Sat, 23 Jan 1999 00:58:15 -0400 | From | "Garst R. Reese" <> | Subject | Re: 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/
| |