Re: best linux emulation for 12-current
On Thu, Oct 4, 2018 at 7:31 PM, tech-lists wrote: Hi, Which is the better package for linux emulation on 12-alpha8 - c6 or c7? Or something else? Emulation is for boinc_client to take linux work c7 is newer, of course it's better, c6 is very old stuff. But you can also just extract any Linux distro (that's not *too* new — Ubuntu 16.04 cloud image works) into a directory and chroot into it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
best linux emulation for 12-current
Hi, Which is the better package for linux emulation on 12-alpha8 - c6 or c7? Or something else? Emulation is for boinc_client to take linux work thanks -- J. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: racct crash/Linux Emulation
On 0828T1207, Larry Rosenman wrote: > On 2015-08-24 11:07, Edward Tomasz Napierała wrote: > > On 0824T0731, Larry Rosenman wrote: > >> On 2015-08-24 03:37, Edward Tomasz Napierała wrote: > >> > On 0823T2028, Larry Rosenman wrote: > >> >> got the below panio, on a linux (world community grid) process exit. > >> >> > >> >> > >> >> borg.lerctr.org dumped core - see /var/crash/vmcore.5 > >> >> > >> >> Sun Aug 23 20:14:24 CDT 2015 > >> >> > >> >> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r287028: > >> >> Sat Aug 22 18:34:59 CDT 2015 > >> >> r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 > >> >> > >> >> panic: racct_sub: freeing 1 of resource 11, which is more than > >> >> allocated 0 for wcgrid_fahv_vina_pr (pid 1140) > >> > > >> > Could you try the patch below? > >> > > >> [removed] > >> > >> Yes, that seems to fix it. THANKS! > > > > Thanks. It's pending review at https://reviews.freebsd.org/D3470. > What's it going to take to get this committed? > > Seems(!) simple enough.. I'd prefer someone who knows this code to take a look and confirm it's indeed the right way to fix it. Don't worry, I won't forget about it :-) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: racct crash/Linux Emulation
On 2015-08-24 11:07, Edward Tomasz Napierała wrote: On 0824T0731, Larry Rosenman wrote: On 2015-08-24 03:37, Edward Tomasz Napierała wrote: > On 0823T2028, Larry Rosenman wrote: >> got the below panio, on a linux (world community grid) process exit. >> >> >> borg.lerctr.org dumped core - see /var/crash/vmcore.5 >> >> Sun Aug 23 20:14:24 CDT 2015 >> >> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r287028: >> Sat Aug 22 18:34:59 CDT 2015 >> r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 >> >> panic: racct_sub: freeing 1 of resource 11, which is more than >> allocated 0 for wcgrid_fahv_vina_pr (pid 1140) > > Could you try the patch below? > [removed] Yes, that seems to fix it. THANKS! Thanks. It's pending review at https://reviews.freebsd.org/D3470. What's it going to take to get this committed? Seems(!) simple enough.. -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: racct crash/Linux Emulation
On 0824T0731, Larry Rosenman wrote: > On 2015-08-24 03:37, Edward Tomasz Napierała wrote: > > On 0823T2028, Larry Rosenman wrote: > >> got the below panio, on a linux (world community grid) process exit. > >> > >> > >> borg.lerctr.org dumped core - see /var/crash/vmcore.5 > >> > >> Sun Aug 23 20:14:24 CDT 2015 > >> > >> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r287028: > >> Sat Aug 22 18:34:59 CDT 2015 > >> r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 > >> > >> panic: racct_sub: freeing 1 of resource 11, which is more than > >> allocated 0 for wcgrid_fahv_vina_pr (pid 1140) > > > > Could you try the patch below? > > > [removed] > > Yes, that seems to fix it. THANKS! Thanks. It's pending review at https://reviews.freebsd.org/D3470. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: racct crash/Linux Emulation
On 2015-08-24 03:37, Edward Tomasz Napierała wrote: On 0823T2028, Larry Rosenman wrote: got the below panio, on a linux (world community grid) process exit. borg.lerctr.org dumped core - see /var/crash/vmcore.5 Sun Aug 23 20:14:24 CDT 2015 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r287028: Sat Aug 22 18:34:59 CDT 2015 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: racct_sub: freeing 1 of resource 11, which is more than allocated 0 for wcgrid_fahv_vina_pr (pid 1140) Could you try the patch below? [removed] Yes, that seems to fix it. THANKS! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 E-Mail: l...@lerctr.org US Mail: 7011 W Parmer Ln, Apt 1115, Austin, TX 78729-6961 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: racct crash/Linux Emulation
On 0823T2028, Larry Rosenman wrote:
> got the below panio, on a linux (world community grid) process exit.
>
>
> borg.lerctr.org dumped core - see /var/crash/vmcore.5
>
> Sun Aug 23 20:14:24 CDT 2015
>
> FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r287028: Sat
> Aug 22 18:34:59 CDT 2015 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER
> amd64
>
> panic: racct_sub: freeing 1 of resource 11, which is more than allocated 0
> for wcgrid_fahv_vina_pr (pid 1140)
Could you try the patch below?
Index: sys/compat/linux/linux_fork.c
===
--- sys/compat/linux/linux_fork.c (revision 287034)
+++ sys/compat/linux/linux_fork.c (working copy)
@@ -285,10 +285,20 @@ linux_clone_thread(struct thread *td, struct linux
p = td->td_proc;
+#ifdef RACCT
+ if (racct_enable) {
+ PROC_LOCK(p);
+ error = racct_add(p, RACCT_NTHR, 1);
+ PROC_UNLOCK(p);
+ if (error != 0)
+ return (EPROCLIM);
+ }
+#endif
+
/* Initialize our td */
error = kern_thr_alloc(p, 0, &newtd);
if (error)
- return (error);
+ goto fail;
cpu_set_upcall(newtd, td);
@@ -369,6 +379,16 @@ linux_clone_thread(struct thread *td, struct linux
td->td_retval[0] = newtd->td_tid;
return (0);
+
+fail:
+#ifdef RACCT
+ if (racct_enable) {
+ PROC_LOCK(p);
+ racct_sub(p, RACCT_NTHR, 1);
+ PROC_UNLOCK(p);
+ }
+#endif
+ return (error);
}
int
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
racct crash/Linux Emulation
got the below panio, on a linux (world community grid) process exit. borg.lerctr.org dumped core - see /var/crash/vmcore.5 Sun Aug 23 20:14:24 CDT 2015 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #46 r287028: Sat Aug 22 18:34:59 CDT 2015 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: racct_sub: freeing 1 of resource 11, which is more than allocated 0 for wcgrid_fahv_vina_pr (pid 1140) GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: racct_sub: freeing 1 of resource 11, which is more than allocated 0 for wcgrid_fahv_vina_pr (pid 1140) cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe2eb3859920 vpanic() at vpanic+0x189/frame 0xfe2eb38599a0 kassert_panic() at kassert_panic+0x132/frame 0xfe2eb3859a10 racct_sub() at racct_sub+0x13e/frame 0xfe2eb3859a50 exit1() at exit1+0xd4/frame 0xfe2eb3859ad0 linux_exit_group() at linux_exit_group+0xd/frame 0xfe2eb3859ae0 ia32_syscall() at ia32_syscall+0x28b/frame 0xfe2eb3859bf0 Xint0x80_syscall() at Xint0x80_syscall+0x95/frame 0xfe2eb3859bf0 --- syscall (252, Linux ELF32, linux_exit_group), rip = 0x817a9d7, rsp = 0xca3c, rbp = 0xca58 --- Uptime: 2m22s Dumping 2881 out of 64454 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% Reading symbols from /boot/kernel/linux.ko.symbols...done. Loaded symbols for /boot/kernel/linux.ko.symbols Reading symbols from /boot/kernel/linux_common.ko.symbols...done. Loaded symbols for /boot/kernel/linux_common.ko.symbols Reading symbols from /boot/kernel/if_lagg.ko.symbols...done. Loaded symbols for /boot/kernel/if_lagg.ko.symbols Reading symbols from /boot/kernel/snd_envy24ht.ko.symbols...done. Loaded symbols for /boot/kernel/snd_envy24ht.ko.symbols Reading symbols from /boot/kernel/snd_spicds.ko.symbols...done. Loaded symbols for /boot/kernel/snd_spicds.ko.symbols Reading symbols from /boot/kernel/coretemp.ko.symbols...done. Loaded symbols for /boot/kernel/coretemp.ko.symbols Reading symbols from /boot/kernel/ichsmb.ko.symbols...done. Loaded symbols for /boot/kernel/ichsmb.ko.symbols Reading symbols from /boot/kernel/smbus.ko.symbols...done. Loaded symbols for /boot/kernel/smbus.ko.symbols Reading symbols from /boot/kernel/ichwd.ko.symbols...done. Loaded symbols for /boot/kernel/ichwd.ko.symbols Reading symbols from /boot/kernel/cpuctl.ko.symbols...done. Loaded symbols for /boot/kernel/cpuctl.ko.symbols Reading symbols from /boot/kernel/cryptodev.ko.symbols...done. Loaded symbols for /boot/kernel/cryptodev.ko.symbols Reading symbols from /boot/kernel/dtraceall.ko.symbols...done. Loaded symbols for /boot/kernel/dtraceall.ko.symbols Reading symbols from /boot/kernel/profile.ko.symbols...done. Loaded symbols for /boot/kernel/profile.ko.symbols Reading symbols from /boot/kernel/dtrace.ko.symbols...done. Loaded symbols for /boot/kernel/dtrace.ko.symbols Reading symbols from /boot/kernel/systrace_freebsd32.ko.symbols...done. Loaded symbols for /boot/kernel/systrace_freebsd32.ko.symbols Reading symbols from /boot/kernel/systrace.ko.symbols...done. Loaded symbols for /boot/kernel/systrace.ko.symbols Reading symbols from /boot/kernel/sdt.ko.symbols...done. Loaded symbols for /boot/kernel/sdt.ko.symbols Reading symbols from /boot/kernel/fasttrap.ko.symbols...done. Loaded symbols for /boot/kernel/fasttrap.ko.symbols Reading symbols from /boot/kernel/fbt.ko.symbols...done. Loaded symbols for /boot/kernel/fbt.ko.symbols Reading symbols from /boot/kernel/dtnfscl.ko.symbols...done. Loaded symbols for /boot/kernel/dtnfscl.ko.symbols Reading symbols from /boot/kernel/dtmalloc.ko.symbols...done. Loaded symbols for /boot/kernel/dtmalloc.ko.symbols Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/ipmi.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi.ko.symbols Reading symbols from /boot/kernel/ipmi_linux.ko.symbols...done. Loaded symbols for /boot/kernel/ipmi_linux.ko.symbols Reading symbols from /boot/kernel/radeonkms.ko.symbols...done. Loaded symbols for /boot/kernel/radeonkms.ko.symbols Reading symbols from /boot/kernel/iicbb.ko.symbols...done. Loaded symbols for /boot/kernel/iicbb.ko.symbols Reading symbols from /boot/kernel/iicbus.ko.symbols...done. Loaded symbols for /boot/kernel/iicbus.ko.symbols Reading symbols from /boot/kernel/iic.ko.symbols...done. Loaded symbols for /boot/kernel/iic.ko.symbols Reading symbols from /boot/kernel/drm2.ko.symbols...done. Loaded symbols for /boot/kernel/drm2.ko.symbols Reading symbols from /boot/kernel/radeonk
Re: panic on yesterday's -CURRENT: linux emulation and vm (lockmgr: locking against myself)
Alan Cox wrote:
On Thu, Sep 25, 2003 at 11:15:57AM -0400, Robert Watson wrote:
...
#6 0xc049f355 in vm_fault (map=0xc6fc1700, vaddr=0, fault_type=1 '\001',
fault_flags=0) at /usr/src/sys/vm/vm_fault.c:219
#7 0xc04eddd9 in trap_pfault (frame=0xdd699b18, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:709
#8 0xc04eda50 in trap (frame=
{tf_fs = -1070333928, tf_es = -1067384816, tf_ds = 16, tf_edi = 0,
tf_esi = -1068054086, tf_ebp = -580281484, tf_isp = -580281532, tf_ebx =
441, tf_edx = -968258896, tf_ecx = 0, tf_eax = -968258896, tf_trapno = 12,
tf_err = 0, tf_eip = -1070325008, tf_cs = 8, tf_eflags = 66178, tf_esp =
0, tf_ss = -1068146900})
at /usr/src/sys/i386/i386/trap.c:418
#9 0xc04dd9e8 in calltrap () at {standard input}:102
#10 0xc04adbde in vm_page_sleep_if_busy (m=0x1b9, also_m_busy=1, msg=0x0)
at /usr/src/sys/vm/vm_page.c:441
#11 0xc04abcfb in vm_object_split (entry=0xc6eea8ac)
at /usr/src/sys/vm/vm_object.c:1226
...
Based upon the above information, it looks like vm_object_split()
followed a bogus vm page pointer. This is in frequently executed
code. So, I would hypothesize a race condition or transient hardware
error is responsible.
When my recent amd64 and i386 pmap changes are replicated on all
platforms that will enable me to introduce additional assertions on
the vm object locking. That may reveal some unsynchronized vm object
accesses that could lead to the above problem.
Alan
___
FWIW, I got this same panic a few days ago, running portinstall shortly
after gnome2 had fillled my fd table for some unknown reason, on
5.1-RELEASE-p5.
Adam
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic on yesterday's -CURRENT: linux emulation and vm (lockmgr: locking against myself)
On Thu, Sep 25, 2003 at 11:15:57AM -0400, Robert Watson wrote:
> ...
> #6 0xc049f355 in vm_fault (map=0xc6fc1700, vaddr=0, fault_type=1 '\001',
> fault_flags=0) at /usr/src/sys/vm/vm_fault.c:219
> #7 0xc04eddd9 in trap_pfault (frame=0xdd699b18, usermode=0, eva=0)
> at /usr/src/sys/i386/i386/trap.c:709
> #8 0xc04eda50 in trap (frame=
> {tf_fs = -1070333928, tf_es = -1067384816, tf_ds = 16, tf_edi = 0,
> tf_esi = -1068054086, tf_ebp = -580281484, tf_isp = -580281532, tf_ebx =
> 441, tf_edx = -968258896, tf_ecx = 0, tf_eax = -968258896, tf_trapno = 12,
> tf_err = 0, tf_eip = -1070325008, tf_cs = 8, tf_eflags = 66178, tf_esp =
> 0, tf_ss = -1068146900})
> at /usr/src/sys/i386/i386/trap.c:418
> #9 0xc04dd9e8 in calltrap () at {standard input}:102
> #10 0xc04adbde in vm_page_sleep_if_busy (m=0x1b9, also_m_busy=1, msg=0x0)
> at /usr/src/sys/vm/vm_page.c:441
> #11 0xc04abcfb in vm_object_split (entry=0xc6eea8ac)
> at /usr/src/sys/vm/vm_object.c:1226
> ...
Based upon the above information, it looks like vm_object_split()
followed a bogus vm page pointer. This is in frequently executed
code. So, I would hypothesize a race condition or transient hardware
error is responsible.
When my recent amd64 and i386 pmap changes are replicated on all
platforms that will enable me to introduce additional assertions on
the vm object locking. That may reveal some unsynchronized vm object
accesses that could lead to the above problem.
Alan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic on yesterday's -CURRENT: linux emulation and vm (lockmgr: locking against myself)
Running -CURRENT from yesterday:
FreeBSD paprika 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Wed Sep 24 19:42:45
EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PAPRIKAMAC i386
MAC, mac_mls, mac_biba, X11, KDE, vic, sdr, xchat. When I ran aim, the
system panicked. Trace below. Please let me know if more information
would be useful.
panic: lockmgr: locking against myself
panic messages:
---
panic: lockmgr: locking against myself
syncing disks, buffers remaining... 3850 3850 3849 3849 3849 3849 3849
3849 3849
3849 3849 3849 3849 3849 3849 3849 3849 3849 3849 3849 3849 3849
giving up on 3349 buffers
Uptime: 14h13m32s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320
336 3
52 368 384 400 416 432 448 464 480 496
0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc034bed8 in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc034c267 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc032baad in lockmgr (lkp=0xc6fc173c, flags=2, interlkp=0x100,
td=0xc6498ab0) at /usr/src/sys/kern/kern_lock.c:439
#4 0xc04a424a in _vm_map_lock_read (map=0x0, file=0x0, line=0)
at /usr/src/sys/vm/vm_map.c:378
#5 0xc04a7d78 in vm_map_lookup (var_map=0xdd699a30, vaddr=0,
fault_typea=1 '\001', out_entry=0xdd699a34, object=0x0, pindex=0x0,
out_prot=0x0, wired=0xdd6999f8) at /usr/src/sys/vm/vm_map.c:2888
#6 0xc049f355 in vm_fault (map=0xc6fc1700, vaddr=0, fault_type=1 '\001',
fault_flags=0) at /usr/src/sys/vm/vm_fault.c:219
#7 0xc04eddd9 in trap_pfault (frame=0xdd699b18, usermode=0, eva=0)
at /usr/src/sys/i386/i386/trap.c:709
#8 0xc04eda50 in trap (frame=
{tf_fs = -1070333928, tf_es = -1067384816, tf_ds = 16, tf_edi = 0,
tf_esi = -1068054086, tf_ebp = -580281484, tf_isp = -580281532, tf_ebx =
441, tf_edx = -968258896, tf_ecx = 0, tf_eax = -968258896, tf_trapno = 12,
tf_err = 0, tf_eip = -1070325008, tf_cs = 8, tf_eflags = 66178, tf_esp =
0, tf_ss = -1068146900})
at /usr/src/sys/i386/i386/trap.c:418
#9 0xc04dd9e8 in calltrap () at {standard input}:102
#10 0xc04adbde in vm_page_sleep_if_busy (m=0x1b9, also_m_busy=1, msg=0x0)
at /usr/src/sys/vm/vm_page.c:441
#11 0xc04abcfb in vm_object_split (entry=0xc6eea8ac)
at /usr/src/sys/vm/vm_object.c:1226
#12 0xc04a702a in vm_map_copy_entry (src_map=0xc6fc1700,
dst_map=0xc6fc1e00,
src_entry=0xc6eea8ac, dst_entry=0xc701803c)
at /usr/src/sys/vm/vm_map.c:2347
#13 0xc04a73ee in vmspace_fork (vm1=0xc6fc1700)
at /usr/src/sys/vm/vm_map.c:2488
#14 0xc04a201e in vm_forkproc (td=0xc6498ab0, p2=0xc714d1e4,
td2=0xc714bab0,
flags=20) at /usr/src/sys/vm/vm_glue.c:624
#15 0xc032340e in fork1 (td=0xc6498ab0, flags=20, pages=0,
procp=0xdd699cc4)
at /usr/src/sys/kern/kern_fork.c:654
#16 0xc032239b in fork (td=0xc6498ab0, uap=0xdd699d10)
at /usr/src/sys/kern/kern_fork.c:102
#17 0xc4260fab in linux_fork (td=0xc6498ab0, args=0x0)
at /usr/src/sys/i386/linux/linux_machdep.c:280
#18 0xc04ee503 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 671827304, tf_esi = 0,
tf_ebp = -1090520360, tf_isp = -580280972, tf_ebx = 671837948, tf_edx = 1,
tf_ecx = 1, tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 675477303,
tf_cs = 31, tf_eflags = 582, tf_esp = -1090520388, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1006
#19 0xc04dda3d in Xint0x80_syscall () at {standard input}:144
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux emulation busted
On Tue, Mar 25, 2003 at 12:58:35AM +0900, [EMAIL PROTECTED] wrote: > On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: > > I had a working Linux world on my laptop. I upgraded my kernel and > > acroread4 stopped working. Now all I get is: > > > > Exited with error code: 0x400e0009. > > > > after a whole lot of disk access when I try to run it. This worked on > > a December kernel for sure. I'm pretty sure it was working as late as > > a January 15th kernel. It hasn't worked on a March 1st and subsequent > > kernels. I'm not sure where it broke inbetween. Has anybody else > > seen this? > > I've also seen this on two versions of -STABLE, one built this morning, > and another built around February 24th. Ugh, I've found the fact that I was trying to start acrobat reader in Japanese mode (LANG set to ja_JP.eucJP) without installing Japanese font pack. After having installed ports/japanese/acroread5-jpnfont, acroread5 began to work without a problem. So maybe mine has nothing to do with what Warner was seeing. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation busted
[EMAIL PROTECTED] wrote: > Mensaje citado por "M. Warner Losh" <[EMAIL PROTECTED]>: > | I had a working Linux world on my laptop. I upgraded my kernel and > | acroread4 stopped working. Now all I get is: > | > | Exited with error code: 0x400e0009. > | > | after a whole lot of disk access when I try to run it. This worked on > | a December kernel for sure. I'm pretty sure it was working as late as > | a January 15th kernel. It hasn't worked on a March 1st and subsequent > | kernels. I'm not sure where it broke inbetween. Has anybody else > | seen this? > > Both acroread4 and 5 work for me with Mar 21 and Mar 18 kernels with today's > world. Acroread5 works on another machine with a Mar 10 kernel and today's > world don't seem to have 4 here. Wasn't this a symptom of the recent change, which causes the Linux kernel modules to become out of date with the kernel, if you just expect "make" to work like it should? Specifically, you are probably running without the modules, or with old versions of the modules. There was a long discussion on (I believe) this list, about two weeks ago. I don't know why the change was made (and I don't like it, either). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation busted
Hi, On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: > I had a working Linux world on my laptop. I upgraded my kernel and > acroread4 stopped working. Now all I get is: > > Exited with error code: 0x400e0009. > > after a whole lot of disk access when I try to run it. This worked on > a December kernel for sure. I'm pretty sure it was working as late as > a January 15th kernel. It hasn't worked on a March 1st and subsequent > kernels. I'm not sure where it broke inbetween. Has anybody else > seen this? I've also seen this on two versions of -STABLE, one built this morning, and another built around February 24th. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation busted
On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: > I had a working Linux world on my laptop. I upgraded my kernel and > acroread4 stopped working. Now all I get is: Is acroread4 multithreaded ? Because since about 2 months all multithreaded linux binaries have stopped working for me; I don't know if this because the new glibc 2.2.93 ( I upgraded at the same time to RH 8.0 ) or something in the linux emulation ( I couldn't spot any relevant change there). I didn't have yet the time to investigate, but: - I could reproduce it with small multithreaded test programs. - It seems that the 'thread model' (i.e. what parameters are passed to clone()) hasn't changed in glibc 2.3 Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation busted
> Date: Mon, 24 Mar 2003 08:40:55 -0700 (MST) > From: "M. Warner Losh" <[EMAIL PROTECTED]> > Sender: [EMAIL PROTECTED] > > I had a working Linux world on my laptop. I upgraded my kernel and > acroread4 stopped working. Now all I get is: > > Exited with error code: 0x400e0009. > > after a whole lot of disk access when I try to run it. This worked on > a December kernel for sure. I'm pretty sure it was working as late as > a January 15th kernel. It hasn't worked on a March 1st and subsequent > kernels. I'm not sure where it broke inbetween. Has anybody else > seen this? My kernel was built on March 21 and acroread V4 is running just fine as is Netscape. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation busted
Mensaje citado por "M. Warner Losh" <[EMAIL PROTECTED]>: | I had a working Linux world on my laptop. I upgraded my kernel and | acroread4 stopped working. Now all I get is: | | Exited with error code: 0x400e0009. | | after a whole lot of disk access when I try to run it. This worked on | a December kernel for sure. I'm pretty sure it was working as late as | a January 15th kernel. It hasn't worked on a March 1st and subsequent | kernels. I'm not sure where it broke inbetween. Has anybody else | seen this? Warner, Both acroread4 and 5 work for me with Mar 21 and Mar 18 kernels with today's world. Acroread5 works on another machine with a Mar 10 kernel and today's world don't seem to have 4 here. Hope that helps, ed - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux emulation busted
I had a working Linux world on my laptop. I upgraded my kernel and acroread4 stopped working. Now all I get is: Exited with error code: 0x400e0009. after a whole lot of disk access when I try to run it. This worked on a December kernel for sure. I'm pretty sure it was working as late as a January 15th kernel. It hasn't worked on a March 1st and subsequent kernels. I'm not sure where it broke inbetween. Has anybody else seen this? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multithreaded binaries dump core in linux emulation
Linux has changed their threading ans is adding some threading 'support' into the kernel. It is unlikely that our emulation supports that support yet. it would certainly be nice to know what they are doing.. On Tue, 18 Feb 2003, Enache Adrian wrote: > I'm using a very recent FreeBSD-current ( ~ 4 days ago ). > > Since I upgraded my linux installation to RH 8.0 > ( ~ 2 months ), I'm not able to run multithreaded binaries under > linux emulation any more. > > ( I hope you understand me - I don't want to install another > set of native mozilla, ooffice and other bloats :-) ). > > That mean: > glibc 2.2.93 > linuxthreads 0.10 > > They used to work fine with older glibc - and no significant > change has occurred since then in the linux emulation code. > > I cannot test with other system since I don't have either > an older glibc & stuff or an older FreeBSD at hand. > > Is anyone else aware of this problem or should I try to > investigate it myself ? > > Thanks & Regards > Adi > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
multithreaded binaries dump core in linux emulation
I'm using a very recent FreeBSD-current ( ~ 4 days ago ). Since I upgraded my linux installation to RH 8.0 ( ~ 2 months ), I'm not able to run multithreaded binaries under linux emulation any more. ( I hope you understand me - I don't want to install another set of native mozilla, ooffice and other bloats :-) ). That mean: glibc 2.2.93 linuxthreads 0.10 They used to work fine with older glibc - and no significant change has occurred since then in the linux emulation code. I cannot test with other system since I don't have either an older glibc & stuff or an older FreeBSD at hand. Is anyone else aware of this problem or should I try to investigate it myself ? Thanks & Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation Panic
On Mon, Jan 13, 2003 at 10:59:08AM -0800, Chuck McCrobie wrote: > Two panics produced when using Linux emulation on a > machine CVSUP'ed two hours ago. Both very easy to > produce. What? You didn't want accurate Linux emulation. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation Panic
Chuck McCrobie wrote: Thank you. That was it. Booted from /boot/cvsup/kernel, loaded modules from /boot/kernel/*. Now, if I can just figure out "read-conf" and friends in loader. It seems I have to manually: loader> unload loader> set kernel=cvsup loader> set kernelname=/boot/cvsup/kernel loader> set module_path=/boot/cvsup loader> boot Try "boot-conf cvsup". At one time, I was deciding whether modify boot or not to do this, and end up deciding against it for compatibility reasons. I have been repenting of it ever since. I want to have two different kernels - one I know works (older -current) and the latest cvsup of -current. Then, I would like to: loader> "some-command-to-load-alternate-configuration" I suppose that's read-conf, but that doesn't seem to like me :( I have: /boot/cvsup.conf as: unload kernel=cvsup kernelname=/boot/cvsup/kernel module_path=/boot/cvsup then I use: loader> read-conf cvsup.conf but the changes don't take effect. Oh well, maybe some more experimentation later... Thanks, Chuck McCrobie --- Kenneth Culver wrote: >What exactly were you running? I use linux emulation >on -CURRENT right now >for mozilla and a few other packages, and havn't had >any panics... you >might have your kernel modules out of sync with your >kernel. > >Ken > >On Mon, 13 Jan 2003, Chuck McCrobie wrote: > > >>Two panics produced when using Linux emulation on > >a > >>machine CVSUP'ed two hours ago. Both very easy to >>produce. Am I the only one running Linux > >emulation on > >> -current? Or is something wacked-ifed with this >>machine? >> >>Thanks, >> >>Chuck McCrobie >>[EMAIL PROTECTED] >> __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] patent: A method of publicizing inventions so others can copy them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation Panic
On 13-Jan-2003 Chuck McCrobie wrote: > Thank you. That was it. Booted from > /boot/cvsup/kernel, loaded modules from > /boot/kernel/*. Now, if I can just figure out > "read-conf" and friends in loader. > > It seems I have to manually: > > loader> unload > loader> set kernel=cvsup > loader> set kernelname=/boot/cvsup/kernel > loader> set module_path=/boot/cvsup > loader> boot > > I want to have two different kernels - one I know > works (older -current) and the latest cvsup of > -current. > > Then, I would like to: > > loader> "some-command-to-load-alternate-configuration" > > I suppose that's read-conf, but that doesn't seem to > like me :( > > I have: /boot/cvsup.conf as: > > unload > kernel=cvsup > kernelname=/boot/cvsup/kernel > module_path=/boot/cvsup > > then I use: > > loader> read-conf cvsup.conf > > but the changes don't take effect. Oh well, maybe > some more experimentation later... Just do 'boot cvsup' and it should do what you want for this case. (Booting from a differently named kernel than the default) > Thanks, > > Chuck McCrobie > > > --- Kenneth Culver <[EMAIL PROTECTED]> wrote: >> What exactly were you running? I use linux emulation >> on -CURRENT right now >> for mozilla and a few other packages, and havn't had >> any panics... you >> might have your kernel modules out of sync with your >> kernel. >> >> Ken >> >> On Mon, 13 Jan 2003, Chuck McCrobie wrote: >> >> > Two panics produced when using Linux emulation on >> a >> > machine CVSUP'ed two hours ago. Both very easy to >> > produce. Am I the only one running Linux >> emulation on >> > -current? Or is something wacked-ifed with this >> > machine? >> > >> > Thanks, >> > >> > Chuck McCrobie >> > [EMAIL PROTECTED] >> > > > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation Panic
Thank you. That was it. Booted from /boot/cvsup/kernel, loaded modules from /boot/kernel/*. Now, if I can just figure out "read-conf" and friends in loader. It seems I have to manually: loader> unload loader> set kernel=cvsup loader> set kernelname=/boot/cvsup/kernel loader> set module_path=/boot/cvsup loader> boot I want to have two different kernels - one I know works (older -current) and the latest cvsup of -current. Then, I would like to: loader> "some-command-to-load-alternate-configuration" I suppose that's read-conf, but that doesn't seem to like me :( I have: /boot/cvsup.conf as: unload kernel=cvsup kernelname=/boot/cvsup/kernel module_path=/boot/cvsup then I use: loader> read-conf cvsup.conf but the changes don't take effect. Oh well, maybe some more experimentation later... Thanks, Chuck McCrobie --- Kenneth Culver <[EMAIL PROTECTED]> wrote: > What exactly were you running? I use linux emulation > on -CURRENT right now > for mozilla and a few other packages, and havn't had > any panics... you > might have your kernel modules out of sync with your > kernel. > > Ken > > On Mon, 13 Jan 2003, Chuck McCrobie wrote: > > > Two panics produced when using Linux emulation on > a > > machine CVSUP'ed two hours ago. Both very easy to > > produce. Am I the only one running Linux > emulation on > > -current? Or is something wacked-ifed with this > > machine? > > > > Thanks, > > > > Chuck McCrobie > > [EMAIL PROTECTED] > > __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation Panic
What exactly were you running? I use linux emulation on -CURRENT right now for mozilla and a few other packages, and havn't had any panics... you might have your kernel modules out of sync with your kernel. Ken On Mon, 13 Jan 2003, Chuck McCrobie wrote: > Two panics produced when using Linux emulation on a > machine CVSUP'ed two hours ago. Both very easy to > produce. Am I the only one running Linux emulation on > -current? Or is something wacked-ifed with this > machine? > > Thanks, > > Chuck McCrobie > [EMAIL PROTECTED] > > > > > 1. cd /usr/ports/emulators/linux_base ; make install > (hand-typed, sorry for typo's) > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x2c > fault code = supervisor read, page not present > instruction pointer = 0x08:0xc4670534 > stack pointer = 0x10:0xdcb45c98 > frame pointer = 0x10:0xdcb45c9c > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1516 (glibc_post_upgrade) > kernel: type 12 trap, code=0 > Stopped at stackgap_init+0x14: mol 0x2c(%eax),%edx > > db> trace > stackgrap_init(dcv45cd0,c047d023,c4360c78,c4361540,dcb45ce0) > at stackgap_init+0x14 > linux_execve(c4361540,dcb45d10,dcb45cfc,dcb45d00,3) at > linux_execve+0x17 > syscall(2f,2f,2f,8048816,bfbfea50) at syscall+0x2aa > Xint0x80_syscall() at Xint0x80_syscall+0x1d > --- syscall (11, Linux ELF, linux_execve), > eip=0x80486c2, esp=0xbfbfea2c, ebp=0xbfbfea38 > > > 2. kldload linux ; /compat/linux/sbin/ldconfig > > > > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux Emulation Panic
Two panics produced when using Linux emulation on a machine CVSUP'ed two hours ago. Both very easy to produce. Am I the only one running Linux emulation on -current? Or is something wacked-ifed with this machine? Thanks, Chuck McCrobie [EMAIL PROTECTED] 1. cd /usr/ports/emulators/linux_base ; make install (hand-typed, sorry for typo's) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2c fault code = supervisor read, page not present instruction pointer = 0x08:0xc4670534 stack pointer = 0x10:0xdcb45c98 frame pointer = 0x10:0xdcb45c9c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 1516 (glibc_post_upgrade) kernel: type 12 trap, code=0 Stopped at stackgap_init+0x14: mol 0x2c(%eax),%edx db> trace stackgrap_init(dcv45cd0,c047d023,c4360c78,c4361540,dcb45ce0) at stackgap_init+0x14 linux_execve(c4361540,dcb45d10,dcb45cfc,dcb45d00,3) at linux_execve+0x17 syscall(2f,2f,2f,8048816,bfbfea50) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (11, Linux ELF, linux_execve), eip=0x80486c2, esp=0xbfbfea2c, ebp=0xbfbfea38 2. kldload linux ; /compat/linux/sbin/ldconfig __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hard-locks with Linux emulation
Hi! While using Mulberry (mail/mulberry) the system often locks up completely. Nothing but reset helps then. I don't get any error (WITHNESS* is on). Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mozilla vs linux emulation in -current?
In message <[EMAIL PROTECTED]>, Ian Dowse writes : >IP, but we were throwing away the modified version). Commit if it >works, and I'll look properly tomorrow. Sorry for the breakage. With the one compile error fixed, this seemed to make `telnet 0.0.0.0' work again, so I went ahead and checked it in. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mozilla vs linux emulation in -current?
In message <[EMAIL PROTECTED]>, Peter Wemm writes:
>Has anybody else noticed this in -current? Mozilla hangs for a minute or
>so at regular intervals..
>16:07:31.896548 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(
Sounds like something I may have broken... Need to sleep now, but
you could try the following. I think in_pcbconnect() used to do
some evil stuff where it would modify the supplied sockaddr,
tcp_connect was depending on this, and I failed to notice it
(in_pcbconnect maps a destination address of INADDR_ANY into a local
IP, but we were throwing away the modified version). Commit if it
works, and I'll look properly tomorrow. Sorry for the breakage.
Ian
Index: tcp_usrreq.c
===
RCS file: /dump/FreeBSD-CVS/src/sys/netinet/tcp_usrreq.c,v
retrieving revision 1.83
diff -u -r1.83 tcp_usrreq.c
--- tcp_usrreq.c21 Oct 2002 13:55:50 - 1.83
+++ tcp_usrreq.c24 Oct 2002 01:27:27 -
@@ -876,14 +876,14 @@
if (oinp != inp && (otp = intotcpcb(oinp)) != NULL &&
otp->t_state == TCPS_TIME_WAIT &&
(ticks - otp->t_starttime) < tcp_msl &&
- (otp->t_flags & TF_RCVD_CC))
+ (otp->t_flags & TF_RCVD_CC)) {
+ inp->inp_faddr = oinp->inp_faddr;
+ inp->inp_fport = oinp->inp_fport;
otp = tcp_close(otp);
- else
+ } else
return EADDRINUSE;
}
inp->inp_laddr = laddr;
- inp->inp_faddr = sin->sin_addr;
- inp->inp_fport = sin->sin_port;
in_pcbrehash(inp);
/* Compute window scaling to request. */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: mozilla vs linux emulation in -current?
On Wed, 23 Oct 2002, Peter Wemm wrote: > > Isn't this a rather strange address to try and connect to? :-] > > Wasn't somebody tinkering with the sin_len stuff recently? COMPAT_43 used > to do evil things, and the linux emulation depended on that. mini did bu tI hit him with a clue stick til he backed it out.. it should all still be there > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mozilla vs linux emulation in -current?
Has anybody else noticed this in -current? Mozilla hangs for a minute or so at regular intervals.. PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 676 peter 40 54492K 39760K connec 1 2:48 0.83% 0.83% mozilla-bin ... Proto Recv-Q Send-Q Local Address Foreign Address(state) tcp4 0 0 daintree.20167 *.16001SYN_SENT peter@daintree[4:07pm]/home/src/sys/i386/conf-134> sockstat | grep 676 petermozilla-bi 676 6 stream -> /tmp/.X11-unix/X0 petermozilla-bi 676 34 stream -> 216.145.52.172:1019 petermozilla-bi 676 36 stream -> 216.145.52.172:1019 petermozilla-bi 676 38 stream -> 216.145.52.172:1019 petermozilla-bi 676 40 stream -> 216.145.52.172:1019 petermozilla-bi 676 42 stream -> 216.145.52.172:1019 petermozilla-bi 676 44 stream -> /tmp/.X11-unix/X0 petermozilla-bi 676 49 stream -> 216.145.52.172:1019 petermozilla-bi 676 51 stream -> 216.145.52.172:1019 petermozilla-bi 676 53 tcp4 216.145.52.172:20167 *:16001 petermozilla-bi 676 58 stream -> 216.145.52.172:1019 # tcpdump -i xl0 -s 1500 -n 'port 16001' 16:07:31.896548 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 (DF) 16:07:34.893961 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 (DF) 16:07:38.094055 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 (DF) 16:07:41.294196 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 (DF) 16:07:44.494325 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 16:07:47.694443 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 16:07:53.894682 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 16:08:06.095119 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 16:08:30.296041 216.145.52.172.20167 > 0.0.0.0.16001: S 1175926117:1175926117(0) win 65535 Isn't this a rather strange address to try and connect to? :-] Wasn't somebody tinkering with the sin_len stuff recently? COMPAT_43 used to do evil things, and the linux emulation depended on that. This particular mozilla is rather old, but neither it nor the rest of the linux environment have been touched for months, and up until recently, it was working fine.Unfortunately, I'd let this machine lag behind -current a bit, so I'm not sure when the problem first turned up. Addendum: port 16001 appears to be used by esd (esound daemon), which I do not have installed and have never used. I removed pcm from this machine. It seems mozilla is trying to connect to port 16001, and for some reason it is going out on the wire now.. :-( Isn't tcp supposed to stop this sort of thing from going onto the wire? Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: user-config alt path in Linux emulation
Andrea Campi wrote: > > When running a Linux binary in Linux compat mode, all calls to open(), > readdir() and such, end up calling linux_emul_find() from linux_util.c. > This functions looks for a directory/file with the same name in the > /compat/linux hierarchy. > The net effect is that there is no way to, for instance, back up the > real /usr from Tivoli, etc... as there is no way to get to a real path > if there is anything with the same name inside /compat/linux. > > I'd like to understand if there is any accepted way to work around this > limitation (no, symlinks are not an option :-p), I'm sure not. /compat is already a symlink (to /usr/compat to be precise). What's with symlinks that it can't be an option? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: user-config alt path in Linux emulation
On Wed, Jan 31, 2001 at 12:50:58PM +, Christian Weisgerber wrote: > Andrea Campi <[EMAIL PROTECTED]> wrote: > > > The net effect is that there is no way to, for instance, back up the > > real /usr from Tivoli, etc... as there is no way to get to a real path > > if there is anything with the same name inside /compat/linux. > > Loopback NFS mount. You are right. It's not elegant at all, but it works. The company I work for is a NASP and we're planning to offer companies that colocate at our premises or buy bandwidth from us the opportunity to backup their machines. I would love to also support FreeBSD, even though it's not got a major market share here. With what you suggest it's possible but I have to teach each customer to do this. My proposed solution, while more intrusive, could be packaged as a kld + scripts; writing a script to setup a loopback NFS mount in any situation is not trivial! Now if only the Tivoli client run a little faster (and more reliable)... but this is a different story. If anybody can help... ;-) Bye, Andrea -- Intel: where Quality is job number 0.9998782345! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RFC: user-config alt path in Linux emulation
Andrea Campi <[EMAIL PROTECTED]> wrote: > The net effect is that there is no way to, for instance, back up the > real /usr from Tivoli, etc... as there is no way to get to a real path > if there is anything with the same name inside /compat/linux. Loopback NFS mount. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RFC: user-config alt path in Linux emulation
Background: When running a Linux binary in Linux compat mode, all calls to open(), readdir() and such, end up calling linux_emul_find() from linux_util.c. This functions looks for a directory/file with the same name in the /compat/linux hierarchy. The net effect is that there is no way to, for instance, back up the real /usr from Tivoli, etc... as there is no way to get to a real path if there is anything with the same name inside /compat/linux. I'd like to understand if there is any accepted way to work around this limitation (no, symlinks are not an option :-p), I'm sure not. Proposal: Implement some way to make this behavior user configurable. The easiest way would probably involve a sysctl to turn it on/off but I would like to have more granularity. I could probably store a flag somewhere in elfhints_hdr.spare, but I'm sure there will be a lot of objections to this. I think this could be done in two parts: 1 - A flag to turn path transalation on/off 2 - A version of the syscalls which accept this flag 3 - A shared library implementing just the needed function calls and calling the new syscalls I don't know if I even understand this correctly, never done this before, but I could learn ;-) Another approach would be to somehow teach the kernel which processes to "let alone", but this would be tricky and probably slower. Alternate proposal: If everything else fails, what about mapping the real filesystems somewhere below /compat/linux? Something like: /compat/linux/native/root /compat/linux/native/usr /compat/linux/native/var Actually (I'm thinking about this just as I am writing) this could be the easier and cleaner solution. Note that these must appear to be real mountpoints. Does this need to go through userland NFS? So, let the discussion begin. If there is no interest, I will implement it in the way which is easier to me (which probably would be the last one). If there is interest and anybody volunteers, fine, otherwise I will implement it and put it up somewhere for review. Bye, Andrea -- Secret hacker rule #11: hackers read manuals. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
I'm not sure who all has been messing with the linuxulator in the last couple of days but as of my last several builds (the latest of a cvsup this afternoon) any attempt to manipulate entries in /compat/linux/dev (even to look at them with ls) causes a kernel page fault. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] There are things that are so serious that you can only joke about them. -- Werner Heisenberg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using tape drives in linux emulation
On Wed, Nov 01, 2000 at 11:40:15PM -0800, Marcel Moolenaar wrote: > [cc'd to [EMAIL PROTECTED]; please remove -current on future > replies] > > It's quite likely we don't support less frequently used or very > specialized ioctls. These are mostly implemented on a need-to-have basis > triggered by a can-be-done condition (what?) > > Do you know what you need? Nothing special just rewind, fsf, ... The density or compression stuff is not needed. That's a rewind using FreeBSD mt: 679 mt CALL open(0xbfbff86e,0,0x6) 679 mt NAMI "/dev/nrsa0" 679 mt RET open 3 679 mt CALL ioctl(0x3,MTIOCTOP,0xbfbff5c4) 679 mt RET ioctl 0 And here what claims to be a rewind with the linux app: 682 tapeexercise CALL open(0xbfbff8a8,0x2,0) 682 tapeexercise NAMI "/compat/linux/dev/nrsa0" 682 tapeexercise NAMI "/dev/nrsa0" 682 tapeexercise RET open 3 682 tapeexercise CALL ioctl(0x3,0x40086d01 ,0xbfbff634) 682 tapeexercise RET ioctl -1 errno -22 Unknown error: -22 682 tapeexercise CALL ktrace(0x810b000) 682 tapeexercise RET ktrace 135311360/0x810b000 682 tapeexercise CALL write(0x2,0xbfbfcb9c,0x3e) 682 tapeexercise GIO fd 2 wrote 62 bytes "tapeexercise: rewind ioctl failed, errno 22: Invalid argument " -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Using tape drives in linux emulation
[cc'd to [EMAIL PROTECTED]; please remove -current on future replies] Bernd Walter wrote: > > It seems that linux progs are using foreign ioctls on tape drives > which of course will fail. Of course? > Is there anyone already working on an emulation for these? AFIACT, no. > Are there similar problems for seriel devices? Probably. It's quite likely we don't support less frequently used or very specialized ioctls. These are mostly implemented on a need-to-have basis triggered by a can-be-done condition (what?) Do you know what you need? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Marcel Moolenaar <[EMAIL PROTECTED]> writes: > Linux has the distinction between block and character devices. I don't > see any evidence that block devices can be accessed as character devices > as well (ie: there's /dev/fd0, but no /dev/rfd0). You can do this in Linux, but the way it works is pretty psychotic. They have a special driver that provides a raw character device interface for block devices, and you have to run a userland utility to bind a block device to one of their /dev/raw devices. This is new as of 2.3/2.4, but there are patches to 2.2 to allow it. Actually, it might have been backported and included with later 2.2 kernels, but I haven't been paying a lot of attention. --nat -- nat lanza - research programmer, parallel data lab, cmu scs [EMAIL PROTECTED] http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes: >> In that case, makebdev() has been wrong ever since we changed to >> mount cdevs in FreeBSD. > >In the sense that we would never find the vnode and thus always return >zero stats, right? No, depends on the bmaj <-> cmaj mapping and the truncation. Off the top of my head I think it unlikely that we have found anything. >> You should simply change the makebdev() to makedev() and VBLK to VCHR >> in the vfinddev() right after. > >Right-o :-) > >> It's still mightily bogus though... > >Yes. A more dynamic solution needs to be used that creates mappings (and >dev_t values) on the fly. I guess you're right, but the thought makes me want to barf... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Poul-Henning Kamp wrote: > > So, where do the programs that call this syscall have the udev_t from ? Most likely from stat, lstat and fstat. > Do they know it to be a mountpoint ? That is implied by the way they get the dev_t. > Do the know it to be a bmajor > or cmajor style udev_t ? AFAICT, filesystems are always on block-devices in Linux. > Being Linux they only know one kind, right ? Linux has the distinction between block and character devices. I don't see any evidence that block devices can be accessed as character devices as well (ie: there's /dev/fd0, but no /dev/rfd0). > In that case, makebdev() has been wrong ever since we changed to > mount cdevs in FreeBSD. In the sense that we would never find the vnode and thus always return zero stats, right? > You should simply change the makebdev() to makedev() and VBLK to VCHR > in the vfinddev() right after. Right-o :-) > It's still mightily bogus though... Yes. A more dynamic solution needs to be used that creates mappings (and dev_t values) on the fly. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes: >Poul-Henning Kamp wrote: >> >> >In short: given the (u)dev_t, get the FS statistics and return the >> >number of free blocks and inodes of the FS on that device. >> >> But the udev_t is a (32bit truncated to) 16bit one, right ? > >Correct. > >> In that case it will usually not work: >> >> crw-r- 1 root operator 116, 0x00010002 1 Jan 1970 /dev/ad0 >> crw-r- 1 root operator 116, 0x0002 1 Jan 1970 /dev/ad0s1a >[snip] > >It won't always work. Will will most often not work. >> Considering the fact that we were likely to return statistics for the >> wrong filesystem with the old code, and most likely cannot return >> the right statistics anyway, I think we should just return zero >> for those values (or some other more sensible values) > >I think we should try to return the right statistics in the case where >we have it wrong now instead of returning the wrong statistics in the >case where we have it right now. OK. So, where do the programs that call this syscall have the udev_t from ? Do they know it to be a mountpoint ? Do the know it to be a bmajor or cmajor style udev_t ? Being Linux they only know one kind, right ? In that case, makebdev() has been wrong ever since we changed to mount cdevs in FreeBSD. You should simply change the makebdev() to makedev() and VBLK to VCHR in the vfinddev() right after. It's still mightily bogus though... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Poul-Henning Kamp wrote: > > >In short: given the (u)dev_t, get the FS statistics and return the > >number of free blocks and inodes of the FS on that device. > > But the udev_t is a (32bit truncated to) 16bit one, right ? Correct. > In that case it will usually not work: > > crw-r- 1 root operator 116, 0x00010002 1 Jan 1970 /dev/ad0 > crw-r- 1 root operator 116, 0x0002 1 Jan 1970 /dev/ad0s1a [snip] It won't always work. > Considering the fact that we were likely to return statistics for the > wrong filesystem with the old code, and most likely cannot return > the right statistics anyway, I think we should just return zero > for those values (or some other more sensible values) I think we should try to return the right statistics in the case where we have it wrong now instead of returning the wrong statistics in the case where we have it right now. When we have it wrong, we're likely to return zero anyway. The only case that pops up in my mind that may cause us to return the statistics of a different device than the one intended is when the minor number is a sequence and we've truncated sequence S, with S > 255 into S % 255. This is not very likely. Hmmm... the strange assignment of NFS mounts might be a problem as well (warning: vague recollections in combination with memory leaks of dated info and mental cross-talk may make this statement slightly off :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Andrew Gallatin wrote: > > Marcel Moolenaar writes: > > Wesley Morgan wrote: > > > > > > Anyone having problems with the linuxulator the past couple days? > > > > Define "past couple of days". I have a working linuxulator made on Oct > > 29, 12:25 PST. > > phk took away mkbdev on 10/31. The following "fixes" it, but I > have no idea if it is correct: I'll see if I can upgrade my notebook. I can't track current at the moment on my main box: any kernel built after 10/29 panics at boot with "malloc: wrong bucket" while attaching the rl0 device. I have this with USB when I have a joystick attached to it, but it goes away if I disconnect the joystick at boot time. I have to diagnose both instances before I can send a bug report to the list... -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
In message <[EMAIL PROTECTED]>, Marcel Moolenaar writes: >Poul-Henning Kamp wrote: >> >> I was just looking at that piece of code, and I couldn't entirely >> make out what it was even trying to do. Can somebody more >> linuxolator savy explain what the function linux_ustat() should >> produce. > >The following comment explains what linux_ustat should do: > > /* >* lu.f_fname and lu.f_fpack are not used. They are always zeroed. >* lu.f_tinode and lu.f_tfree are set from the device's super block. >*/ > >linux_ustat fills in a structure with the above mention fields. The >meaning of f_tinode and f_tfree are explained by the following two >statements: > > lu.f_tfree = stat->f_bfree; > lu.f_tinode = stat->f_ffree; > >In short: given the (u)dev_t, get the FS statistics and return the >number of free blocks and inodes of the FS on that device. But the udev_t is a (32bit truncated to) 16bit one, right ? In that case it will usually not work: crw-r- 1 root operator 116, 0x00010002 1 Jan 1970 /dev/ad0 crw-r- 1 root operator 116, 0x0002 1 Jan 1970 /dev/ad0s1a crw-r- 1 root operator 116, 0x00020001 1 Jan 1970 /dev/ad0s1b crw-r- 1 root operator 116, 0x00020004 1 Jan 1970 /dev/ad0s1e crw-r- 1 root operator 116, 0x00020005 1 Jan 1970 /dev/ad0s1f crw-r- 1 root operator 116, 0x00030002 1 Jan 1970 /dev/ad0s2c crw-r- 1 root operator 116, 0x0004 1 Jan 1970 /dev/ad0s3a crw-r- 1 root operator 116, 0x00040003 1 Jan 1970 /dev/ad0s3d Considering the fact that we were likely to return statistics for the wrong filesystem with the old code, and most likely cannot return the right statistics anyway, I think we should just return zero for those values (or some other more sensible values) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Poul-Henning Kamp wrote: > > I was just looking at that piece of code, and I couldn't entirely > make out what it was even trying to do. Can somebody more > linuxolator savy explain what the function linux_ustat() should > produce. The following comment explains what linux_ustat should do: /* * lu.f_fname and lu.f_fpack are not used. They are always zeroed. * lu.f_tinode and lu.f_tfree are set from the device's super block. */ linux_ustat fills in a structure with the above mention fields. The meaning of f_tinode and f_tfree are explained by the following two statements: lu.f_tfree = stat->f_bfree; lu.f_tinode = stat->f_ffree; In short: given the (u)dev_t, get the FS statistics and return the number of free blocks and inodes of the FS on that device. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
I was just looking at that piece of code, and I couldn't entirely
make out what it was even trying to do. Can somebody more
linuxolator savy explain what the function linux_ustat() should
produce.
I also find this comment rather interesting...
/*
* XXX - Don't return an error if we can't find a vnode for the
* device. Our dev_t is 32-bits whereas Linux only has a 16-bits
* dev_t. The dev_t that is used now may as well be a truncated
* dev_t returned from previous syscalls. Just return a bzeroed
* ustat in that case.
*/
Poul-Henning
In message <[EMAIL PROTECTED]>, Andrew Gallatin
writes:
>
>Marcel Moolenaar writes:
> > Wesley Morgan wrote:
> > >
> > > Anyone having problems with the linuxulator the past couple days?
> >
> > Define "past couple of days". I have a working linuxulator made on Oct
> > 29, 12:25 PST.
>
>phk took away mkbdev on 10/31. The following "fixes" it, but I
>have no idea if it is correct:
>
>Drew
>
>Index: compat/linux/linux_stats.c
>===
>RCS file: /home/ncvs/src/sys/compat/linux/linux_stats.c,v
>retrieving revision 1.22
>diff -u -r1.22 linux_stats.c
>--- compat/linux/linux_stats.c 2000/08/22 01:51:11 1.22
>+++ compat/linux/linux_stats.c 2000/11/01 18:34:05
>@@ -360,8 +379,8 @@
> * dev_t returned from previous syscalls. Just return a bzeroed
> * ustat in that case.
> */
>- dev = makebdev(uap->dev >> 8, uap->dev & 0xFF);
>- if (vfinddev(dev, VBLK, &vp)) {
>+ dev = makedev(uap->dev >> 8, uap->dev & 0xFF);
>+ if (vfinddev(dev, VCHR, &vp)) {
>if (vp->v_mount == NULL)
>return (EINVAL);
>stat = &(vp->v_mount->mnt_stat);
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Marcel Moolenaar writes:
> Wesley Morgan wrote:
> >
> > Anyone having problems with the linuxulator the past couple days?
>
> Define "past couple of days". I have a working linuxulator made on Oct
> 29, 12:25 PST.
phk took away mkbdev on 10/31. The following "fixes" it, but I
have no idea if it is correct:
Drew
Index: compat/linux/linux_stats.c
===
RCS file: /home/ncvs/src/sys/compat/linux/linux_stats.c,v
retrieving revision 1.22
diff -u -r1.22 linux_stats.c
--- compat/linux/linux_stats.c 2000/08/22 01:51:11 1.22
+++ compat/linux/linux_stats.c 2000/11/01 18:34:05
@@ -360,8 +379,8 @@
* dev_t returned from previous syscalls. Just return a bzeroed
* ustat in that case.
*/
- dev = makebdev(uap->dev >> 8, uap->dev & 0xFF);
- if (vfinddev(dev, VBLK, &vp)) {
+ dev = makedev(uap->dev >> 8, uap->dev & 0xFF);
+ if (vfinddev(dev, VCHR, &vp)) {
if (vp->v_mount == NULL)
return (EINVAL);
stat = &(vp->v_mount->mnt_stat);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Using tape drives in linux emulation
It seems that linux progs are using foreign ioctls on tape drives which of course will fail. Is there anyone already working on an emulation for these? Are there similar problems for seriel devices? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
From: Marcel Moolenaar <[EMAIL PROTECTED]>
Date: Tue, 31 Oct 2000 22:59:48 -0800
::> Anyone having problems with the linuxulator the past couple days?
::
::Define "past couple of days". I have a working linuxulator made on Oct
::29, 12:25 PST.
By following commit, makebdev() went away.
But there is sys/compat/linux/linux_stats.c:linux_ustat() that still
uses it.
---8<--8<--8<--8<--- Cut Here ---8<--8<--8<--8<---
phk 2000/10/31 02:58:17 PST
Modified files:
sys/i386/i386autoconf.c
sys/kern kern_conf.c
sys/sys conf.h
Log:
Deprecate devsw->d_bmaj entirely.
This removes support for booting current kernels with very old bootblocks.
Device driver writers: Please remove initializations for the d_bmaj
field in your cdevsw{}.
---8<--8<--8<--8<--- Cut Here ---8<--8<--8<--8<---
Hope this helps,
Haro
=--
_ _Munehiro (haro) Matsuda
-|- /_\ |_|_| Business Incubation Dept., Kubota Corp.
/|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome
Chuo-ku Tokyo 103-8310, Japan
Tel: +81-3-3245-3318 Fax: +81-3-3245-3315
Email: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
On Tue, Oct 31, 2000 at 10:59:48PM -0800, Marcel Moolenaar wrote: > Wesley Morgan wrote: > > > > Anyone having problems with the linuxulator the past couple days? > > Define "past couple of days". I have a working linuxulator made on Oct > 29, 12:25 PST. Mine: Mon Oct 30 17:01:15 CET 2000 and works. (using it right now.:-) -- Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Wesley Morgan wrote: > > Anyone having problems with the linuxulator the past couple days? Define "past couple of days". I have a working linuxulator made on Oct 29, 12:25 PST. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Wesley Morgan wrote: > Anyone having problems with the linuxulator the past couple days? > Module fails to load for me, with this message: > link_elf: symbol makebdev undefined Yah, i do. -- // Donny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
linux emulation
Anyone having problems with the linuxulator the past couple days? Module fails to load for me, with this message: link_elf: symbol makebdev undefined -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation ETTW?
In message <[EMAIL PROTECTED]> Jordan Hubbard writes: : > By ETTW i mean estimated time to work :D : : It works right now and has for the last week. If you get out of date : with your modules, on the other hand, you're shooting your own feet off. And the move to the new layout may be shooting you without your knowledge. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation ETTW?
> By ETTW i mean estimated time to work :D It works right now and has for the last week. If you get out of date with your modules, on the other hand, you're shooting your own feet off. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation ETTW?
Tobias Fredriksson wrote: > By ETTW i mean estimated time to work :D > since the last compile a 1/2 days ago the linux emulation on my non-smp > station has failed. Everything that has to use linux emulation crashes the > kernel which is rather bad :/ > > Anybody know when this is schedueled to be looked at / fixed? It works, but you need to have your kernel and modules in sync. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Linux Emulation ETTW?
On 14-Sep-00 Tobias Fredriksson wrote: > By ETTW i mean estimated time to work :D > since the last compile a 1/2 days ago the linux emulation on my non-smp > station has failed. Everything that has to use linux emulation crashes the > kernel which is rather bad :/ > > Anybody know when this is schedueled to be looked at / fixed? You are probably using the wrong modules. Make sure you don't have an old /modules directory lying around since the kernel and modules have moved to /boot/xxx --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux Emulation ETTW?
By ETTW i mean estimated time to work :D since the last compile a 1/2 days ago the linux emulation on my non-smp station has failed. Everything that has to use linux emulation crashes the kernel which is rather bad :/ Anybody know when this is schedueled to be looked at / fixed? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation causes a halt
On Sun, May 14, 2000 at 06:29:59PM +0200, Eric Jacoboni wrote: > > "Jesper" == Jesper Skriver <[EMAIL PROTECTED]> writes: > > Jesper> Just upgraded my laptop from a late march -current to > Jesper> -current as of a couple of hours ago. > > Jesper> When it loads the "Linux binary compatibility" it > Jesper> shutdown, if apm is enabled it looks like when one do a > Jesper> 'shutdown -p now'. > > > Jesper> Anyone seen anything like this ? > > Have you read /usr/src/UPDATING ? No, I thought I could remember, but it works now, I think if we could give a warning instead of a just shutting down, it would be nice. Next time, I will read UPDATING ... /Jesper To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation causes a halt
> "Jesper" == Jesper Skriver <[EMAIL PROTECTED]> writes: Jesper> Just upgraded my laptop from a late march -current to Jesper> -current as of a couple of hours ago. Jesper> When it loads the "Linux binary compatibility" it Jesper> shutdown, if apm is enabled it looks like when one do a Jesper> 'shutdown -p now'. Jesper> Anyone seen anything like this ? Have you read /usr/src/UPDATING ? -- - Éric Jacoboni « No sport, cigars! » (W. Churchill) - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux emulation causes a halt
Hi, Just upgraded my laptop from a late march -current to -current as of a couple of hours ago. When it loads the "Linux binary compatibility" it shutdown, if apm is enabled it looks like when one do a 'shutdown -p now'. When I set linux_enable="NO" in /etc/rc.conf the machine boots properly, but my Linux applications doesn't work. I did a full buildworld, installworld installed the new kernel, and updated /etc with mergemaster ... Anyone seen anything like this ? /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
linux emulation patch committed to -current - recompile linux module
The linux emulation patch has been committed to -current, you must recompile your linux emulation kld. This patch will be MFC'd to 4.x on Friday. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesdayy
Martin Blapp wrote: > I really like to see your fix committed to STABLE. It fixes also the > bad designed Staroffice 5.2 installation for some part (/usr/sbin/test). ...as well as the WordPerfect 2000 for Linux installation. Basically, it sounds like it makes Linux emulation really complete. Although I do agree that there should be a knob to turn this thing on and/or off. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.xwednesday
On Sun, 23 Apr 2000, Matthew Dillon wrote: > There's another good reason to MFC the linux patch on wednesday... > that is, to do it at the same time the SMP cleanup is MFC'd, and that > is because both patch sets require the linux kernel module to be > recompiled and I'd rather not force people to do that twice. > > The SMP patchset, in fact, requires that all kernel modules be > recompiled due to the locks that were removed from the spl*() macros. > This is something I would contemplate doing for 4.0->4.1, but not > something I would consider for 4.1 onward. Even though 4.0 is the > most stable .0 release we've ever had, it's still a .0. > > I wonder if it makes sense to add a release id to the module header > and have the module loader refuse (unless forced) to load modules that > are out-of-date with the kernel? This sounds quite reasonable. Perhaps you should commit the linux patch to -current right now and then merge it on Wednesday. That would give plenty of time for any teething problems to show up. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 20 8442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.xwednesday
Hi Matt, I really like to see your fix committed to STABLE. It fixes also the bad designed Staroffice 5.2 installation for some part (/usr/sbin/test). Thank you for your work ! Martin Martin Blapp, [EMAIL PROTECTED] Improware AG, UNIX solution and service provider Zurlindenstrasse 29, 4133 Pratteln, Switzerland Phone: +41 79 370 26 05, Fax: +41 61 826 93 01 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
> > BTW; whilst I think Poul was entirely the wrong person to raise the > issue, I agree that you probably want to hang back on MFCing the linux > scripting changes for a week or so. This is really just common sense. > recently i added autoload to a usb related kernel module. very handy to havejust like with ifconfing autoloading ethernet drivers. i did an immediate MFC. i was WRONG. i should not have done that. even though it does strike me as an obivious win to have the autoload. lets let every change sit in -current for a little while before the MFC occurs. jmb To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
Mike Muir wrote: > > Nate Williams wrote: > > > I was under the impression that 4.x hasn't been designated as the stable > > branch (yet). That will happen when 4.1 is released, but until that > > happens 3.x is still considered the -stable release. > > That would kinda make sense since cvsuping with tag=RELENG_3 seems to > give me FreeBSD 4.0-STABLE (#0: Sat Apr 22 20:59:03 PDT 2000).. Ok wait im a moron.. been using the stable-supfile instead of the 4.x-stable-supfile.. hm. mike. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
Nate Williams wrote: > I was under the impression that 4.x hasn't been designated as the stable > branch (yet). That will happen when 4.1 is released, but until that > happens 3.x is still considered the -stable release. That would kinda make sense since cvsuping with tag=RELENG_3 seems to give me FreeBSD 4.0-STABLE (#0: Sat Apr 22 20:59:03 PDT 2000).. But besides that, this whole back and forth dont-do-this-do-that charade is going to get pretty juvenile soon.. I mean we're (matt) already at bad memory insults heh so how bout you both kiss/reevaluate and make up before it gets so bad you try to keep away from each other next time you're both at one of these conventions or whatever.. hmm now theres an uncomfortable situation to be in for both sides. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
: :>I do not consider the linux scripting patch to be a major infrastructure :>change, I consider it to be a simple bug fix. If you have a functional :>issue with the patch I'm all ears. If you disagree with my assessment of :>the triviality of the linux scripting patch, then I will ask for a :>second opinion from someone who is not quite so jaded in regards to my :>commits... say Jordan or DG. : : I'm sure you're right that the impact is minor. I'm a little uncomfortable :with immediate MFC's, even though I've been guilty of doing that myself at :times in the past. Can we perhaps compromise and allow for a one day delay? :At least that would catch glaring mistakes like mis-applied patches that :happen sometimes even with highly skilled developers who have only the best :intentions. : :-DG : :David Greenman Sure, no problem. I'll tell you what, I'll commit the linux scripting patch to 5.x on wednesday as originally planned, but since the SMP MFC is being moved to friday (at the very least) I will not MFC the scripting patch to 4.x until friday. ( That is, what I really want to do is to do the SMP MFC and the scripting MFC at the same time so people only have to recompile their kernel modules once. It happens to work out well ). -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
> I wonder if it makes sense to add a release id to the module header > and have the module loader refuse (unless forced) to load modules that > are out-of-date with the kernel? We actually have a whole module dependancy and versioning system more or less ready to go into -current. It could have gone in for 4.0, but we wouldn't have had time to test it. I would avoid rolling anything half-assed at this point in time. BTW; whilst I think Poul was entirely the wrong person to raise the issue, I agree that you probably want to hang back on MFCing the linux scripting changes for a week or so. This is really just common sense. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
>I do not consider the linux scripting patch to be a major infrastructure >change, I consider it to be a simple bug fix. If you have a functional >issue with the patch I'm all ears. If you disagree with my assessment of >the triviality of the linux scripting patch, then I will ask for a >second opinion from someone who is not quite so jaded in regards to my >commits... say Jordan or DG. I'm sure you're right that the impact is minor. I'm a little uncomfortable with immediate MFC's, even though I've been guilty of doing that myself at times in the past. Can we perhaps compromise and allow for a one day delay? At least that would catch glaring mistakes like mis-applied patches that happen sometimes even with highly skilled developers who have only the best intentions. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com Pave the road of life with opportunities. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
On Sun, 23 Apr 2000, Matthew Dillon wrote: > If core wants to change the current rules, that's fine by me. As I > said before I think the breakage that we thought would happen with 5.x > due to the BSDI merger that prompted the loose rules for 4.x is > overrated, and the rules should probably be reverted back to standard. Well, unless I missed some REQUIREMENT in "the rules", there is nothing to prevent you from applying to your own actions the policy that you think should be the rule and apply to everyone. Just because you COULD do something and stay within the letter of the law, that is no excuse to do it. Although I suspect that your change is a general improvement, it is certainly a change that might have adverse impact on some users. Therefore, I think that if should receive closer and more widespread review before being committed to any of the "stable" branches. Personally, I will use the attitude that you have been expressing to justify my claim that FreeBSD is still just a "developers' sandbox". Until ALL the developers start to think about changes from the perspective of the end user, it will remain so. IMHO, there is entirely too much rush to force untested changes on everyone. Every change should flow through the slowly widening set of exposures afforded by gradual commits to the various forums. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
> >Core should consider reverting the special rules that were originally > >created with the expectation of major breakage in 5.x back to > >the set of rules we had for 3.x and 4.x. > > I have no idea what special rules you are talking about for 4.x/5.x. > > 4.x-stable is a -stable tree and shall be treated as such. I was under the impression that 4.x hasn't been designated as the stable branch (yet). That will happen when 4.1 is released, but until that happens 3.x is still considered the -stable release. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
: :In message <[EMAIL PROTECTED]>, Matthew Dillon writes: : :>Core should consider reverting the special rules that were originally :>created with the expectation of major breakage in 5.x back to :>the set of rules we had for 3.x and 4.x. : :I have no idea what special rules you are talking about for 4.x/5.x. : :4.x-stable is a -stable tree and shall be treated as such. Really, then you have a short memory. Why don't we ask Jordan for a clarification. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
: : :Matt, : :I will say it this last time: : : Your patch does not qualify for immediate MFC. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 And I will say this to you for the last time: Under the current rules my patch DOES qualify for an immediate MFC. Hell, by the current rules developers can commit to 4.x FIRST! And unless you can come up with something better then this superior attitude bullshit, that is what is going to happen in this particular case. Frankly, what it comes down to is that if DG or Jordan ask me to delay, I know they will have a damn good reason for doing so and I will of course delay. But you, Poul, have used up all your brownie points and I'm getting tired of you changing the rules to suit your current whims, and then changing them again to justify your own commits. Your duel-standard is getting rather tired and your words simply do not have any weight with me any more. If core wants to change the current rules, that's fine by me. As I said before I think the breakage that we thought would happen with 5.x due to the BSDI merger that prompted the loose rules for 4.x is overrated, and the rules should probably be reverted back to standard. -Matt Matthew Dillon <[EMAIL PROTECTED]> :[EMAIL PROTECTED] | TCP/IP since RFC 956 :FreeBSD coreteam member | BSD since 4.3-tahoe :Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >Core should consider reverting the special rules that were originally >created with the expectation of major breakage in 5.x back to >the set of rules we had for 3.x and 4.x. I have no idea what special rules you are talking about for 4.x/5.x. 4.x-stable is a -stable tree and shall be treated as such. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
:> : :> :-- :> :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :> :>I think you're confused, Poul. I've gone over the commits made :>to the tree by people over the last few months and frankly there :>are dozens of simultanious -current and -stable commits. A quick :>check shows that most of them are trivial bug fixes. : :And look at how many of them had to be patched, re-merged, etc. IMHO :people are getting way way to loose with MFC right after a commit. I :don't even want to see a MFC for a 1 character spelling fixed MFC'ed :in less than 3 days anymore. : :-- :Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] Perfectly acceptable to me ... *IF* core decides to change the rules they've made for the current development trees (stable and current) and makes an official statement that covers everyone rather then just Matt. I think the work required to accomplish the BSDI merger is overrated anyway (in regards to the source tree). I kinda expected the BSDI people to start working on it immediately but obviously the pace is going to be a lot slower. Core should consider reverting the special rules that were originally created with the expectation of major breakage in 5.x back to the set of rules we had for 3.x and 4.x. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
> > : > :In message <[EMAIL PROTECTED]>, Matthew Dillon writes: > : > :>There's another good reason to MFC the linux patch on wednesday... > :>that is, to do it at the same time the SMP cleanup is MFC'd, and that > :>is because both patch sets require the linux kernel module to be > :>recompiled and I'd rather not force people to do that twice. > : > :Matt, this is not a valid reason either. > : > :Unless there is *urgent* and *overriding* reasons, and that basically > :means that the security-officer says so, all changes must be shaken > :out in -current first. > : > :That's just the way it is Matt. Get used to it. > : > :-- > :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > >I think you're confused, Poul. I've gone over the commits made >to the tree by people over the last few months and frankly there >are dozens of simultanious -current and -stable commits. A quick >check shows that most of them are trivial bug fixes. And look at how many of them had to be patched, re-merged, etc. IMHO people are getting way way to loose with MFC right after a commit. I don't even want to see a MFC for a 1 character spelling fixed MFC'ed in less than 3 days anymore. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
Matt, I will say it this last time: Your patch does not qualify for immediate MFC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
> There's another good reason to MFC the linux patch on wednesday... > that is, to do it at the same time the SMP cleanup is MFC'd, and that > is because both patch sets require the linux kernel module to be > recompiled and I'd rather not force people to do that twice. > > The SMP patchset, in fact, requires that all kernel modules be > recompiled due to the locks that were removed from the spl*() macros. In that case I have a strong objection to the SMP patchset being merged to 4.0. I have kernel modules in object format only that are working now, which this would break :-(. Either way, nothing ever should me an immediate MFC, even a blantant security hole should not be MFC'ed immediately, code needs to be tested, and some other person might find a few niglets that need cleaned up before you MFC it. Who knows, you might even break the system, and an immediate MFC would break both at once. Never, ever should anything be immediatly merged. IMHO, no even spelling fixes, as I have seen those done wrong, patched, and MFC'ed again. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
: :In message <[EMAIL PROTECTED]>, Matthew Dillon writes: : :>There's another good reason to MFC the linux patch on wednesday... :>that is, to do it at the same time the SMP cleanup is MFC'd, and that :>is because both patch sets require the linux kernel module to be :>recompiled and I'd rather not force people to do that twice. : :Matt, this is not a valid reason either. : :Unless there is *urgent* and *overriding* reasons, and that basically :means that the security-officer says so, all changes must be shaken :out in -current first. : :That's just the way it is Matt. Get used to it. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I think you're confused, Poul. I've gone over the commits made to the tree by people over the last few months and frankly there are dozens of simultanious -current and -stable commits. A quick check shows that most of them are trivial bug fixes. I will also point out that the current STABLE and CURRENT trees are being treated as a special case. Jordan himself said so! And that he has made a specific statement indicating that people could develop in the 4.x tree due to the potential breakage in the 5.x tree. This seems entirely appropriate to me. If the rules have changed since that announcement, then I recommend that core make an official statement to correct it. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >I'm sorry, Poul, but you are going to have to come up with better >reasoning then that. > >Not all changes committed to -current require a waiting period before >being MFC'd to stable. Specifically, simple and obvious bug fixes >certainly do not need a waiting period. Matt, This does not apply to your patch. The "simple and obvious" loophole applies to spelling fixes and similar, not to anything which changes behaviour of the system. Your current patch does not qualify for immediate MFC status unless the security officer says so. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes: : :>:I don't see anything justifying an immediate MFC in this patch. Please :>:allow the normal waiting period to elapse before you MFC. :> :>Unless you can justify a reason for it NOT to be MFC'd immediately, I :>see no reason to wait for this particular baby. : :Sorry, Matt, that is not the way it works. Unless there is an overriding :issue, things do not get MFC'ed immediately. : :You have only cited reasons why it would be much more convenient for you :personally to MFC right away, that is not enough to justify an immediate :MFC. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I'm sorry, Poul, but you are going to have to come up with better reasoning then that. Not all changes committed to -current require a waiting period before being MFC'd to stable. Specifically, simple and obvious bug fixes certainly do not need a waiting period. My reasoning has nothing to do with what is or is not personally convenient for me, and frankly your insinuation that it is is rather insulting. After all, look how long I've waited for the SMP patches before considering MFCing those? It sure would have been more convenient for me to MFC them a week after 5.0 stabilized and before I began work on other patch sets but I didn't. Due to the gravity of the changes I thought it would be best to give them a really good test run under 5.x (and note: I received permission from Jordan to MFC the SMP stuff weeks ago, and even with that permission I decided to wait). I do not consider the linux scripting patch to be a major infrastructure change, I consider it to be a simple bug fix. If you have a functional issue with the patch I'm all ears. If you disagree with my assessment of the triviality of the linux scripting patch, then I will ask for a second opinion from someone who is not quite so jaded in regards to my commits... say Jordan or DG. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >There's another good reason to MFC the linux patch on wednesday... >that is, to do it at the same time the SMP cleanup is MFC'd, and that >is because both patch sets require the linux kernel module to be >recompiled and I'd rather not force people to do that twice. Matt, this is not a valid reason either. Unless there is *urgent* and *overriding* reasons, and that basically means that the security-officer says so, all changes must be shaken out in -current first. That's just the way it is Matt. Get used to it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
There's another good reason to MFC the linux patch on wednesday... that is, to do it at the same time the SMP cleanup is MFC'd, and that is because both patch sets require the linux kernel module to be recompiled and I'd rather not force people to do that twice. The SMP patchset, in fact, requires that all kernel modules be recompiled due to the locks that were removed from the spl*() macros. This is something I would contemplate doing for 4.0->4.1, but not something I would consider for 4.1 onward. Even though 4.0 is the most stable .0 release we've ever had, it's still a .0. I wonder if it makes sense to add a release id to the module header and have the module loader refuse (unless forced) to load modules that are out-of-date with the kernel? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >:I don't see anything justifying an immediate MFC in this patch. Please >:allow the normal waiting period to elapse before you MFC. > >Unless you can justify a reason for it NOT to be MFC'd immediately, I >see no reason to wait for this particular baby. Sorry, Matt, that is not the way it works. Unless there is an overriding issue, things do not get MFC'ed immediately. You have only cited reasons why it would be much more convenient for you personally to MFC right away, that is not enough to justify an immediate MFC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
:
:In message <[EMAIL PROTECTED]>, Matthew Dillon writes:
:
:>I intend to commit this to -current and immediately MFC it to -stable.
:>I don't expect there to be any controversy though I'm sure there is a
:>cleaner way to do it.
:
:I don't see anything justifying an immediate MFC in this patch. Please
:allow the normal waiting period to elapse before you MFC.
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
It's such a simple patch, and it fixes problems that would otherwise
exist under 4.x's linux emulation, and it only effects the linux
emulation. And I've been running it for a while under 5.x already (as
I said). And I put it up for a review 2 weeks ago. And it makes no
major infrastructure changes to the core system.
Unless you can justify a reason for it NOT to be MFC'd immediately, I
see no reason to wait for this particular baby. That is, unless you
*like* linux applications that use scripts to start running FreeBSD
utilities even when you have all the appropriate linux packages
installed!
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
In message <[EMAIL PROTECTED]>, Matthew Dillon writes: >I intend to commit this to -current and immediately MFC it to -stable. >I don't expect there to be any controversy though I'm sure there is a >cleaner way to do it. I don't see anything justifying an immediate MFC in this patch. Please allow the normal waiting period to elapse before you MFC. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux emulation scripting fix to be committed to 5.x and 4.x wednesday
This is the same patch I put up for review two weeks ago. I got one positive comment back and nothing else, so I presume nobody has a problem with it. I've been running with it for a while but have only tested it with a few linux applications (Java (jre, jdk), and the oracle installer stuff). http://www.backplane.com/FreeBSD4/linux-script-01.diff This patch fixes #! paths in scripts run under linux emulation, causing /compat/linux to be searched for the script binary when the script is exec'd from a program running under emulation. Often linux applications run scripts to do various things. Without this patch these scripts effectively 'break out' of the linux emulation (for example, use the FreeBSD version of /bin/sh instead of the linux version of /bin/sh) which can cause compatibility problems, especially when the scripts run other utilities that they expect to be the linux version rather then FreeBSD version (install, cat, grep, etc...) I intend to commit this to -current and immediately MFC it to -stable. I don't expect there to be any controversy though I'm sure there is a cleaner way to do it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation problems - path length restrictions inlinux_rename
At 11:09 AM -0700 2000/4/10, Matthew Dillon wrote: > I can't say I'm impressed. Oracle itself is a very complete relational > database, but their replication capabilities suck. They only do > non-quorum fully synchronous replication or non-quorum fully > asynchronous replication. They do not do quorum synchronous replication > (which means that if you have 10 replicated sites in a multi-master > configuration, and one goes down, you are screwed), and they don't > support asynchronous (to the transaction) commits in a replicated > environment (where basically a site sends the phase-2 commit > acknowledgement before actually committing the physical data, which makes > transactions go a whole lot faster without sacrificing much, if any, > data integrity). Also, Oracle's replication is built out of SQL > procedures and triggers and is very, *VERY* fragile. If you make > one mistake running management commands, you screw the whole cluster. > Unacceptable! Alright. I think I understood about one word out of ten out of that, enough to know that you feel they have some problems and to have some inkling as to what they might be. So, this begs the inevitable next question -- what do you think *does* work well with respect to these issues? And what problems does this system have that perhaps Oracle doesn't? -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation problems - path length restrictions in linux_rename
Matthew Dillon wrote: > Basically I had to take the linux_base port, and then chroot into > /usr/compat/linux and install the rpm's for most of redhat, including > the compiler environment, and the ld.so and ldd piece from slackware > (because redhat's is broken under emulation). Sounds like a lot of work. This is what I did (besides installing linux_base and linux_devtools) 1) Get JRE to work in /usr/local/jre/bin edit jre, rmiregister, checkVersion: #!/compat/linux/bin/sh [OK, I lied. I said I only changed a single script :-] create /compat/linux/bin/arch to contain: #!/bin/sh uname -m rm /compat/linux/usr/bin/ldd 2) Get Oracle8i installer to work set DISPLAY set TMP link /compat/linux/etc/mtab to /etc/fstab It took me a couple of hours, but I didn't spend any time getting an actual database working. Oracle8i was fairly new at the time and I wasn't going to waste any time tracing bugs that also existed on Linux. My primary concern was the Linuxulator :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation problems - path length restrictions in linux_rename
:> (No, this fix alone isn't enough to do an oracle install, it's just too :> grungy a beast). : :In 1999Q2 I did an install of Oracle8i, which failed due to an installer :problem, IIRC. I only modified 1 script to overcome the shell execution :problem. You are using Blackdown JDK, are you? : :-- :Marcel Moolenaar Yes. I've managed to get oracle-8i installed on FreeBSD under linux emulation, but it was a chore. It took 30 hours before I was able to figure it out from a combination of playing around and locating the redhat install support documents on oracle's site. Basically I had to take the linux_base port, and then chroot into /usr/compat/linux and install the rpm's for most of redhat, including the compiler environment, and the ld.so and ldd piece from slackware (because redhat's is broken under emulation). On the upside, this actually worked - I have a nearly complete linux environment (fortunately oracle does not require /proc or /dev in general), I was able to download and install the linux jre 1.1.6 (which oracle requires), and I was able to get most of oracle installed. Unfortunately, half the oracle Java assistants still don't work. Fortunately the base binaries work and I was able to create databases. Unfortunately, the oracle install process is fragile and a chore - you screwup, you start over. I can't say I'm impressed. Oracle itself is a very complete relational database, but their replication capabilities suck. They only do non-quorum fully synchronous replication or non-quorum fully asynchronous replication. They do not do quorum synchronous replication (which means that if you have 10 replicated sites in a multi-master configuration, and one goes down, you are screwed), and they don't support asynchronous (to the transaction) commits in a replicated environment (where basically a site sends the phase-2 commit acknowledgement before actually committing the physical data, which makes transactions go a whole lot faster without sacrificing much, if any, data integrity). Also, Oracle's replication is built out of SQL procedures and triggers and is very, *VERY* fragile. If you make one mistake running management commands, you screw the whole cluster. Unacceptable! -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation problems - path length restrictions in linux_rename
[CC to -emulation as well] Matthew Dillon wrote: > > I just noticed that the reserved area of the user stack that the linux > emulator uses to copy modified paths is only 256 bytes long. > > linux_rename() makes two calls to the path munging code, which means > that the two path arguments are limited in aggregate to 256 bytes, > which is wrong. I've kept a PR open that addresses this indirectly. The real bug is that there's no length checking, which means that if the combined length exceeds 256, bad things happen. > I've also noted another major issue with the linux emulation, and that > is with shell script execution. > > If you are running a linux binary which then fork/exec's a shell script, > the interpreter path at the top of the shell script does not undergo > the path munging code, which breaks the script out of the linux emulation > mode (because it runs the FreeBSD /bin/sh, /bin/csh, etc instead of the > linux version). This is something I have on my TODO list for a while now. > I have a fix for the latter problem. It's fairly trivial. > Without a fix the only way one can reliably run serious linux apps > (like an oracle install for example) under linux emulation is to > chroot into /compat/linux. I would appreciate a review: It basicly looks all right. I haven't tried it yet and also didn't study it closely. I was thinking along the lines of creating more of a "context". This way we can have different behaviour depending on "context". Context being "FreeBSD" or "Linux" or whatever. I hoped to save the addition of "try-this-first" pointers to existing structures. Not that it is bad in general, but I somehow always end up thinking that there's something structurally wrong if you end up doing it like that :-) > (No, this fix alone isn't enough to do an oracle install, it's just too > grungy a beast). In 1999Q2 I did an install of Oracle8i, which failed due to an installer problem, IIRC. I only modified 1 script to overcome the shell execution problem. You are using Blackdown JDK, are you? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
linux emulation problems - path length restrictions in linux_rename
I just noticed that the reserved area of the user stack that the linux emulator uses to copy modified paths is only 256 bytes long. linux_rename() makes two calls to the path munging code, which means that the two path arguments are limited in aggregate to 256 bytes, which is wrong. I've also noted another major issue with the linux emulation, and that is with shell script execution. If you are running a linux binary which then fork/exec's a shell script, the interpreter path at the top of the shell script does not undergo the path munging code, which breaks the script out of the linux emulation mode (because it runs the FreeBSD /bin/sh, /bin/csh, etc instead of the linux version). I have a fix for the latter problem. It's fairly trivial. Without a fix the only way one can reliably run serious linux apps (like an oracle install for example) under linux emulation is to chroot into /compat/linux. I would appreciate a review: http://www.backplane.com/FreeBSD4/linux-script-01.diff (No, this fix alone isn't enough to do an oracle install, it's just too grungy a beast). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linux Emulation patches
On Wed, 23 Feb 2000, Victor A. Salaman wrote: > Anyways, after sending email to marcel and peter with the patches, I haven't > even received a reply. :-( > > So therefore, I'm posting them here, in case anyone wants to commit > them at all. I feel 4.0 shouldn't go out with a known broken linux > emulation. One way to make sure your patch does not get lost is to create a GNATS report with the patch and priority=high by means of send-pr or the web form at http://www.freebsd.org/support.html#gnats. Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Linux Emulation patches
Hi:
I was wondering who
mantains the Linux Emulation? I have some patches that were sent to me for
FreeBSD-3.4, I have converted them to FreeBSD 4.0-Current for Linux emulation
problems. Specifically anyone trying to use any program that opens a server
socket will get bitten by the emulation unless these patches are applied (
JServ, Resin, Tomcat are some Java programs affected by this... and since
Sun hasn't release a JDK 1.2 for FreeBSD, well, the only way to run some
server programs is with Blackdown, but without these patches they are
useless ).
Anyways, after
sending email to marcel and peter with the patches, I haven't even received a
reply. So therefore, I'm posting them here, in case anyone wants to commit them
at all. I feel 4.0 shouldn't go out with a known broken linux emulation.
---
/usr/src/sys/i386/linux/linux_file.c Wed Feb 23 16:11:50 2000+++
/usr/src/sys/i386/linux/linux_file.orig Wed Feb 23 16:11:37 2000@@
-199,6 +199,12 @@ } */ fcntl_args;
struct linux_flock
linux_flock; struct flock
*bsd_flock;+ struct filedesc *fdp;+
struct file *fp;+ struct vnode *vp;+
long pgid;+ struct pgrp *pgrp;+
struct tty *tp; caddr_t
sg; dev_t dev; @@ -283,9 +289,47
@@ case
LINUX_F_SETOWN: case
LINUX_F_GETOWN:- fcntl_args.cmd = args->cmd == LINUX_F_SETOWN ?
F_SETOWN : F_GETOWN;- fcntl_args.arg = args->arg;- return
fcntl(p, &fcntl_args); + /*+ * We need to route around
the normal fcntl() for these calls,+ * since it uses TIOC{G,S}PGRP,
which is too restrictive for+ * Linux F_{G,S}ETOWN semantics. For
sockets, this problem+ * does not exist.+ */+ fdp =
p->p_fd;+ if ((u_int)args->fd >= fdp->fd_nfiles
||+ (fp = fdp->fd_ofiles[args->fd]) ==
NULL)+ return EBADF;+ if (fp->f_type ==
DTYPE_SOCKET) {+ fcntl_args.cmd = args->cmd ==
LINUX_F_SETOWN ? F_SETOWN : F_GETOWN;+
fcntl_args.arg =
args->arg;+ return fcntl(p, &fcntl_args);
+ }+ vp = (struct vnode *)fp->f_data;+ dev =
vn_todev(vp);+ if (dev == NODEV)+ return
EINVAL;+ if (!(devsw(dev)->d_flags &
D_TTY))+ return EINVAL;+ tp =
dev->si_tty;+ if (!tp)+ return
EINVAL;+ if (args->cmd == LINUX_F_GETOWN)
{+ p->p_retval[0] = tp->t_pgrp ?
tp->t_pgrp->pg_id : NO_PID;+ return
0;+ }+ if ((long)args->arg <= 0)
{+ pgid = -(long)args->arg;+ } else
{+ struct proc *p1 =
pfind((long)args->arg);+ if (p1 ==
0)+ return (ESRCH);+ pgid =
(long)p1->p_pgrp->pg_id;+ }+ pgrp =
pgfind(pgid);+ if (pgrp == NULL || pgrp->pg_session !=
p->p_session)+ return
EPERM;+ tp->t_pgrp = pgrp;+ return
0; } return
EINVAL; }
---
/usr/src/sys/i386/linux/linux_socket.c Wed Feb 23 16:11:50 2000+++
/usr/src/sys/i386/linux/linux_socket.orig Wed Feb 23 16:11:48 2000@@
-441,11 +441,6 @@ caddr_t name; int
*anamelen; } */ bsd_args;-
struct fcntl_args /* {- int fd;- int
cmd;- long arg;- } */
f_args; int
error; if ((error=copyin((caddr_t)args,
(caddr_t)&linux_args, sizeof(linux_args@@ -453,24 +448,7
@@ bsd_args.s =
linux_args.s; bsd_args.name =
(caddr_t)linux_args.addr; bsd_args.anamelen =
linux_args.namelen;-- if (error = oaccept(p,
&bsd_args))- return error;-
/*- * linux appears not to copy flags from the
parent socket to the- * accepted one, so we must
clear the flags in the new descriptor.-
*/- f_args.fd = p->p_retval[0];-
f_args.cmd = F_SETFL;- f_args.arg = 0;-
/*- * we ignore errors here since otherwise we would
have an open file- * descriptor that wasn't returned
to the user.- */- (void)
fcntl(p, &f_args);- /* put the file descriptor back as
the return value */- p->p_retval[0] =
f_args.fd;- return 0;+ return
oaccept(p, &bsd_args); } struct
linux_getsockname_args {
Re: ASDM and linux emulation?
Fritz & Doug,
Doug White <[EMAIL PROTECTED]> writes:
> On Thu, 27 Jan 2000, F. Heinrichmeyer wrote:
>
> > I would like to use an ASDM (backup software) with linux-emulation. I
> > get
> > the following in /var/log/messages:
> >
> > es-i2 /kernel: linux: syscall setresuid is obsoleted\
> > or not implemented (pid=41052)
> > Jan 27 13:12:42 es-i2 /kernel: pid 41052 (dsm), \
> > uid 0: exited on signal 11 (core dumped)
>
> What FreeBSD is this? I've run the v3 client under linux mode without bad
> syscalls (just that silly pathmunging stuff that I need to renew the fight
> over).
Perhaps you are running the backup as root while Fritz has a setuid
root program? In any case, please find attacked a patch that
implements setresuid. The patch is relative to 3.3 but should port
pretty easily to current.
Fritz, if this cures your problems, please drop me a note.
Cheers,
Björn
--
_ _ ,___.
Bjorn Gronvall (Björn Grönvall)/___/|
Swedish Institute of Computer Science | ||
PO Box 1263, S-164 29 Kista, Sweden| Schroedingers ||
Email: [EMAIL PROTECTED], Phone +46 -8 633 15 25 | Cat |/
Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---'
--- linux_misc.c2000/01/29 10:23:54 1.1
+++ linux_misc.c2000/01/29 11:40:28
@@ -797,6 +797,44 @@
}
int
+linux_setresuid(p, uap)
+ struct proc *p;
+ struct linux_setresuid_args *uap;
+{
+ struct setreuid_args bsd_args;
+
+ /* Allow setresuid iff the saved effective uid is left unchanged. */
+ if (uap->suid != -1 && uap->suid != p->p_cred->p_svuid) {
+ printf("Linux-emul(%d): setresuid(%d, %d, %d) not supported\n",
+ p->p_pid, uap->ruid, uap->euid, uap->suid);
+ return ENOSYS;
+ }
+ bsd_args.ruid = uap->ruid;
+ bsd_args.euid = uap->euid;
+ /* uap->suid is unchanged */
+ return setreuid(p, &bsd_args);
+}
+
+int
+linux_setresgid(p, uap)
+ struct proc *p;
+ struct linux_setresgid_args *uap;
+{
+ struct setregid_args bsd_args;
+
+ /* Allow setresgid iff the saved effective gid is left unchanged. */
+ if (uap->sgid != -1 && uap->sgid != p->p_cred->p_svgid) {
+ printf("Linux-emul(%d): setresgid(%d, %d, %d) not supported\n",
+ p->p_pid, uap->rgid, uap->egid, uap->sgid);
+ return ENOSYS;
+ }
+ bsd_args.rgid = uap->rgid;
+ bsd_args.egid = uap->egid;
+ /* uap->sgid is unchanged */
+ return setregid(p, &bsd_args);
+}
+
+int
linux_msync(struct proc *p, struct linux_msync_args *args)
{
struct msync_args bsd_args;
--- linux_proto.h 2000/01/29 10:28:59 1.1
+++ linux_proto.h 2000/01/29 11:08:53
@@ -402,6 +402,16 @@
int new_len;char new_len_[PAD_(int)];
int flags; char flags_[PAD_(int)];
};
+struct linux_setresuid_args {
+ int ruid; char ruid_[PAD_(int)];
+ int euid; char euid_[PAD_(int)];
+ int suid; char suid_[PAD_(int)];
+};
+struct linux_setresgid_args {
+ int rgid; char rgid_[PAD_(int)];
+ int egid; char egid_[PAD_(int)];
+ int sgid; char sgid_[PAD_(int)];
+};
struct linux_rt_sigaction_args {
int sig;char sig_[PAD_(int)];
struct linux_new_sigaction *act;char act_[PAD_(struct
linux_new_sigaction *)];
@@ -528,6 +538,8 @@
intlinux_sched_setscheduler __P((struct proc *, struct
linux_sched_setscheduler_args *));
intlinux_sched_getscheduler __P((struct proc *, struct
linux_sched_getscheduler_args *));
intlinux_mremap __P((struct proc *, struct linux_mremap_args *));
+intlinux_setresuid __P((struct proc *, struct linux_setresuid_args *));
+intlinux_setresgid __P((struct proc *, struct linux_setresgid_args *));
intlinux_rt_sigaction __P((struct proc *, struct linux_rt_sigaction_args *));
intlinux_rt_sigprocmask __P((struct proc *, struct linux_rt_sigprocmask_args *));
intlinux_chown __P((struct proc *, struct linux_chown_args *));
--- linux_syscall.h 2000/01/29 10:43:49 1.1
+++ linux_syscall.h 2000/01/29 11:09:30
@@ -162,7 +162,9 @@
#defineLINUX_SYS_sched_rr_get_interval 161
#defineLINUX_SYS_nanosleep 162
#defineLINUX_SYS_linux_mremap 163
+#defineLINUX_SYS_linux_setresuid 164
#defineLINUX_SYS_poll 168
+#defineLINUX_SYS_linux_setresgid 170
#defineLINUX_SYS_linux_rt_sigaction174
#defineLINUX_SYS_linux_rt_sigprocmask 175
#define
Re: ASDM and linux emulation?
On Thu, 27 Jan 2000, F. Heinrichmeyer wrote: > I would like to use an ASDM (backup software) with linux-emulation. I > get > the following in /var/log/messages: > > es-i2 /kernel: linux: syscall setresuid is obsoleted\ > or not implemented (pid=41052) > Jan 27 13:12:42 es-i2 /kernel: pid 41052 (dsm), \ > uid 0: exited on signal 11 (core dumped) What FreeBSD is this? I've run the v3 client under linux mode without bad syscalls (just that silly pathmunging stuff that I need to renew the fight over). I have a hacked linux.ko that lets dsmc backup what you think it will back up, but the SCO version is a better fit. I should try it on my workstation. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ASDM and linux emulation?
On Thu, Jan 27, 2000 at 01:39:38PM +0100, F. Heinrichmeyer wrote: > I would like to use an ASDM (backup software) with linux-emulation. I > get > the following in /var/log/messages: Have you tried the SCO client with the IBCS module loaded? I've been using it with great success for a while. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
