Re: Linux emulation busted

2003-03-25 Thread qhwt
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

2003-03-24 Thread eculp
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


Re: Linux emulation busted

2003-03-24 Thread Kevin Oberman
 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

2003-03-24 Thread Enache Adrian
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

2003-03-24 Thread qhwt
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

2003-03-24 Thread Terry Lambert
[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 Panic

2003-01-14 Thread Daniel C. Sobral
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

2003-01-14 Thread David O'Brien
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

2003-01-13 Thread Kenneth Culver
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

 sorry, no panic information for this one


 __
 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



Re: Linux Emulation Panic

2003-01-13 Thread Chuck McCrobie
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

2003-01-13 Thread John Baldwin

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

2000-11-02 Thread Michael Harnois

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: linux emulation

2000-11-01 Thread Munehiro Matsuda

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

2000-11-01 Thread Andrew Gallatin


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



Re: linux emulation

2000-11-01 Thread Poul-Henning Kamp


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

2000-11-01 Thread Marcel Moolenaar

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

2000-11-01 Thread Poul-Henning Kamp

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

2000-11-01 Thread Marcel Moolenaar

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

2000-11-01 Thread Marcel Moolenaar

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

2000-11-01 Thread Poul-Henning Kamp

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

2000-11-01 Thread Marcel Moolenaar

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

2000-11-01 Thread Poul-Henning Kamp

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

2000-11-01 Thread Nat Lanza

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/rawN 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

2000-10-31 Thread Donny Lee

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



Re: linux emulation

2000-10-31 Thread Marcel Moolenaar

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

2000-10-31 Thread Szilveszter Adam

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 ETTW?

2000-09-14 Thread Warner Losh

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?

2000-09-13 Thread Daniel O'Connor


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



Re: Linux Emulation ETTW?

2000-09-13 Thread John Baldwin

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?

2000-09-13 Thread Jordan Hubbard

 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 causes a halt

2000-05-14 Thread Jesper Skriver

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

2000-05-14 Thread Eric Jacoboni

 "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



Re: Linux emulation scripting fix to be committed to 5.x and 4.xwednesday

2000-04-24 Thread Martin Blapp


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.xwednesday

2000-04-24 Thread Doug Rabson

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.x wednesdayy

2000-04-24 Thread Frank Mayhar

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.x wednesday

2000-04-23 Thread Poul-Henning Kamp

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

2000-04-23 Thread Poul-Henning Kamp

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

2000-04-23 Thread Matthew Dillon

: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

2000-04-23 Thread Poul-Henning Kamp

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

2000-04-23 Thread Matthew Dillon

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

2000-04-23 Thread Poul-Henning Kamp

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



Re: Linux emulation scripting fix to be committed to 5.x and 4.x wednesday

2000-04-23 Thread Matthew Dillon


:
: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

2000-04-23 Thread Matthew Dillon


:
: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

2000-04-23 Thread Rodney W. Grimes

 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

2000-04-23 Thread Poul-Henning Kamp


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

2000-04-23 Thread Rodney W. Grimes

 
 :
 :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

2000-04-23 Thread Matthew Dillon

: :
: :--
: :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

2000-04-23 Thread David Greenman

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

2000-04-23 Thread Mike Smith

 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

2000-04-23 Thread Poul-Henning Kamp

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

2000-04-23 Thread Matthew Dillon


:
: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

2000-04-23 Thread Matthew Dillon


:
:
: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

2000-04-23 Thread Matthew Dillon


:
: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

2000-04-23 Thread Mike Muir

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

2000-04-23 Thread Mike Muir

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

2000-04-23 Thread Nate Williams

 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

2000-04-23 Thread Richard Wackerbarth

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

2000-04-23 Thread Jonathan M. Bresler

 
 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 problems - path length restrictions in linux_rename

2000-04-10 Thread Marcel Moolenaar

[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



Re: linux emulation problems - path length restrictions in linux_rename

2000-04-10 Thread Matthew Dillon

: (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

2000-04-10 Thread Marcel Moolenaar

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 inlinux_rename

2000-04-10 Thread Brad Knowles

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 patches

2000-02-23 Thread Gerald Pfeifer

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



Re: linux emulation broken.. (solution)

1999-10-25 Thread Chris Csanady

 I *know* someone else said it wasn't so, but just 3 weeks ago I had this
 very problem, with word perfect, and it works just fine now.  Are you sure
 you have a really up to date linux_base port installed?  It was recently
 changed, a *lot* of new libs added, and I'd really like an answer on this,
 whether I'm right or wrong.

Well, I found a solution to my problems with running linux-netscape and word
perfect.  It looks like it was not the linux emulation code that was at fault.

I recently installed a real redhat 6.1, and mounted it on /compat/linux.  Now
all is well--so I can only assume it is some weird interaction between the
linux_base port and my system.  Maybe it is related to using XFree86 3.9.15,
but I don't have the time to test that theory right now.

Certainly not a great solution, but if things are broke for you this at least
works.

Chris Csanady


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: linux emulation broken.. (solution)

1999-10-25 Thread Chuck Robey

On Mon, 25 Oct 1999, Chris Csanady wrote:

  I *know* someone else said it wasn't so, but just 3 weeks ago I had this
  very problem, with word perfect, and it works just fine now.  Are you sure
  you have a really up to date linux_base port installed?  It was recently
  changed, a *lot* of new libs added, and I'd really like an answer on this,
  whether I'm right or wrong.
 
 Well, I found a solution to my problems with running linux-netscape and word
 perfect.  It looks like it was not the linux emulation code that was at fault.
 
 I recently installed a real redhat 6.1, and mounted it on /compat/linux.  Now
 all is well--so I can only assume it is some weird interaction between the
 linux_base port and my system.  Maybe it is related to using XFree86 3.9.15,
 but I don't have the time to test that theory right now.
 
 Certainly not a great solution, but if things are broke for you this at least
 works.

No, like I said, when I *really* updated my Linux libs (and the linux_base
port had very newly updated libs when I posted this) my problems
evaporated, which is why I urged others to do it.  I don't know why it
didn't work for you, but at least it's done for you now.

 
 Chris Csanady
 


Chuck Robey| Interests include C programming, Electronics,
213 Lakeside Dr. Apt. T-1  | communications, and signal processing.
Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and
(301) 220-2114 |   jaunt.mat.net : FreeBSD-current(Alpha)




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: linux emulation broken..

1999-10-15 Thread Marc van Woerkom

 This is weird, I use linux netscape and word perfect all the time, and the
 only problems I see are memory leaks I knew were there (in the
 applications, not FreeBSD)

Indeed. The Linux version was more stable than the FreeBSD version 
(that one can't digest the Slashdot site for some strange reason).
But since Monday it tears my box down.

I won't blame the emulation however until I have recompiled the system
successfully and recompiled XFree86 and this behaviour continues to 
happen.

Regards,
Marc



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: linux emulation broken..

1999-10-14 Thread Marc van Woerkom

 (im)perfect.  I was using the linux version of netscape, until
 recently when it began hanging for long periods of time during
 network or disk activity.  

Calling up linux-netscape-4.61 causes my system to freeze for a 
couple of seconds, then it reboots.

This is either related to some recent changes, or my system being 
not in a consistent state.

Regards,
Marc


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: linux emulation broken..

1999-10-14 Thread Marcel Moolenaar

Chris Csanady wrote:
[snip]
 it is still broken.  I don't have time to go into it any further
 right now, but I thought I would check if others are having
 similar difficulties.

No.

 I have a lot to do, and it is just extremely irritating right
 now.  I swear, nothing relating to linux ever works..

So why do you think the Linuxulator is broken then?

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking  Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: linux emulation broken..

1999-10-14 Thread Kenneth Wayne Culver

This is weird, I use linux netscape and word perfect all the time, and the
only problems I see are memory leaks I knew were there (in the
applications, not FreeBSD)


=
| Kenneth Culver  | FreeBSD: The best OS around.|
| Unix Systems Administrator  | ICQ #: 24767726 |
| and student at The  | AIM: AgRSkaterq |
| The University of Maryland, | Website: (Under Construction)   |
| College Park.   | http://www.wam.umd.edu/~culverk/|
=

On Thu, 14 Oct 1999, Marc van Woerkom wrote:

  (im)perfect.  I was using the linux version of netscape, until
  recently when it began hanging for long periods of time during
  network or disk activity.  
 
 Calling up linux-netscape-4.61 causes my system to freeze for a 
 couple of seconds, then it reboots.
 
 This is either related to some recent changes, or my system being 
 not in a consistent state.
 
 Regards,
 Marc
 
 
 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



Re: linux emulation broken..

1999-10-14 Thread David Scheidt

On Thu, 14 Oct 1999, Marc van Woerkom wrote:

  (im)perfect.  I was using the linux version of netscape, until
  recently when it began hanging for long periods of time during
  network or disk activity.  
 
 Calling up linux-netscape-4.61 causes my system to freeze for a 
 couple of seconds, then it reboots.

Is your linux emulation module out of date?  I got bit by this the other
day.  It will causee quite a nice panic.  Fixed that (options COMPAT_LINUX).


David Scheidt 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: linux emulation broken..

1999-10-14 Thread Chuck Robey

On Thu, 14 Oct 1999, Kenneth Wayne Culver wrote:

 This is weird, I use linux netscape and word perfect all the time, and the
 only problems I see are memory leaks I knew were there (in the
 applications, not FreeBSD)
 

I had equal problems a little while back.  Make sure you have the
linux_base port installed, it has a far more up to date set of libs.

 
 On Thu, 14 Oct 1999, Marc van Woerkom wrote:
 
   (im)perfect.  I was using the linux version of netscape, until
   recently when it began hanging for long periods of time during
   network or disk activity.  
  
  Calling up linux-netscape-4.61 causes my system to freeze for a 
  couple of seconds, then it reboots.
  
  This is either related to some recent changes, or my system being 
  not in a consistent state.
  
  Regards,
  Marc
  
  
  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
 


Chuck Robey| Interests include C programming, Electronics,
213 Lakeside Dr. Apt. T-1  | communications, and signal processing.
Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and
(301) 220-2114 |   jaunt.mat.net : FreeBSD-current(Alpha)




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Linux emulation

1999-10-04 Thread Marcel Moolenaar

Chuck Robey wrote:
 
 I just tried to use my copy of WordPerfect 8 to decode an rtf document,
 like I've done before the signal change, and boy was I surprised.  The
 machine locked up for 10 seconds, then spontaneously rebooted.
 
 Anyone else have this experience with Linux emulation?

Some reports of crashes have come to me, but none contained the
necessary information or simply weren't reproducable. If you think
there's something wrong and you want me to take a look at it, you'll
have to give me something to work on.

-- 
Marcel Moolenaarmailto:[EMAIL PROTECTED]
SCC Internetworking  Databases   http://www.scc.nl/
The FreeBSD projectmailto:[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message