date:20011115

M.D. , sise 572 chaussée

2001-11-15 Thread Vande Walle Daniel


Warning
Unable to process data: 
multipart/mixed;boundary==_NextPart_000_004D_01BE0CA9.BF0CA9F0

Re: FreeBSD on vmware

2001-11-15 Thread Glenn Gombert



 Thanks for the tip Ian ...this works great! I have applied this patch
to my desktop system ...and the FreeBSD Current kernel with this patch
applied boots right up now...anyone else running Current under FreeBSD
would fine it helpful to do as well

Glenn G.


 Ian Dowse [EMAIL PROTECTED] wrote:
 In message [EMAIL PROTECTED], Robert
 Watson writ
 es:
 I've had -STABLE run fine, but of late have had a lot of trouble with
 -current.  Userland processes during the boot sequence seem to spend
 a lot
 of time just spinning -- it's not clear to me what the cause is, and
 I
 haven't had time to debug.
 
 Someone mentioned on a list somewhere that vmware takes forever to
 emulate the cmpxchg instruction, and that using the I386_CPU version
 of atomic_cmpset_int() helps a lot. I noticed a major vmware slowdown
 with -current sometime in September, so I tried avoiding the
 cmpxchg's and things got much faster. Below is the patch I use
 (using this outside vmware on SMP hardware is a bad idea :-).
 
 Ian
 
 Index: atomic.h
 ===
 RCS file: /dump/FreeBSD-CVS/src/sys/i386/include/atomic.h,v
 retrieving revision 1.21
 diff -u -r1.21 atomic.h
 --- atomic.h  2001/10/08 20:58:24 1.21
 +++ atomic.h  2001/10/09 18:35:25
 @@ -111,7 +111,7 @@
   * Returns 0 on failure, non-zero on success
   */
  
 -#if defined(I386_CPU)
 +#if defined(I386_CPU) || 1
  static __inline int
  atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
  {
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-hackers in the body of the message
 

__
FREE voicemail, email, and fax...all in one place.
Sign Up Now! http://www.onebox.com


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

-STABLE NVidia drivers

2001-11-15 Thread David Rufino


Hi,

Just thought I would mention my -STABLE NVidia drivers have been working for 
the past week, as far as 2D and XVideo goes. Available on CVS at 
http://sourceforge.net/projects/nv-bsd.

David

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

RE: linux JVMs not handling SEGV well.

2001-11-15 Thread Koster, K.J.


[ CC'd to freebsd-java, please followup there too ]

Dear Andrew,

This question is better asked on -java, so I forwarded you question. There
are many hardcore JVM hackers on that list.

 
 I'm using 4.x-stable, linux-base-6.x, and am encountering a lot of
 turbulence with both Sun's jdk1.3.x HotSpot JVM and IBM's 
 linux jdk1.3.x JVM.

Well, considering that technically we don't actually have any Java VM post
1.1.8... :-)


 I have a buggy 3rdparty java app that occasionally causes a 
 null pointer
 exception to be thrown. While not fatal for the app (the exception is
 correctly caught), it's most often fatal for the JVM. The SUN 
 jvm SEGV's (
 doesn't correctly catch the SIGNAL ), while the IBM jvm seems to get
 locked in kernel mode - only responding to SIGKILL and 
 chewing up tons of
 'system' cpu time. The common denominator here is that both 
 JITs utilize
 linux threads. When I use a non-threaded JIT, the problem 
 doesn't occur.

 The problem is readily reproducible, but I'm not sure how to debug it.
 I've played with truss and ktrace, but I think it's time to 
 begin thinking
 about using the kernel debugger.
 
Could you perhaps provide a simple code sample that allows us to reproduce
the problem?

Kees Jan


 You are only young once,
   but you can stay immature all your life.

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

Re: FreeBSD on vmware

2001-11-15 Thread John Baldwin



On 15-Nov-01 Glenn Gombert wrote:
 
  Thanks for the tip Ian ...this works great! I have applied this patch
 to my desktop system ...and the FreeBSD Current kernel with this patch
 applied boots right up now...anyone else running Current under FreeBSD
 would fine it helpful to do as well

Perhaps we need an 'options VMWARE' that this could be triggered off of.

 Glenn G.
 
 
  Ian Dowse [EMAIL PROTECTED] wrote:
 In message [EMAIL PROTECTED], Robert
 Watson writ
 es:
 I've had -STABLE run fine, but of late have had a lot of trouble with
 -current.  Userland processes during the boot sequence seem to spend
 a lot
 of time just spinning -- it's not clear to me what the cause is, and
 I
 haven't had time to debug.
 
 Someone mentioned on a list somewhere that vmware takes forever to
 emulate the cmpxchg instruction, and that using the I386_CPU version
 of atomic_cmpset_int() helps a lot. I noticed a major vmware slowdown
 with -current sometime in September, so I tried avoiding the
 cmpxchg's and things got much faster. Below is the patch I use
 (using this outside vmware on SMP hardware is a bad idea :-).
 
 Ian
 
 Index: atomic.h
 ===
 RCS file: /dump/FreeBSD-CVS/src/sys/i386/include/atomic.h,v
 retrieving revision 1.21
 diff -u -r1.21 atomic.h
 --- atomic.h 2001/10/08 20:58:24 1.21
 +++ atomic.h 2001/10/09 18:35:25
 @@ -111,7 +111,7 @@
   * Returns 0 on failure, non-zero on success
   */
  
 -#if defined(I386_CPU)
 +#if defined(I386_CPU) || 1
  static __inline int
  atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src)
  {
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-hackers in the body of the message
 
 
 __
 FREE voicemail, email, and fax...all in one place.
 Sign Up Now! http://www.onebox.com
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with unsubscribe freebsd-hackers 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-hackers in the body of the message

[hackers] Re: wake up on lan driver support

2001-11-15 Thread David Gilbert


 Hellmuth == Hellmuth Michaelis [EMAIL PROTECTED] writes:

 Yes, definitely (thanks for the addition!).  Many older power
 supplies cannot supply enough current on the +5VSB rail to support
 WOL.

Hellmuth I have some experience with an fxp0: Intel Pro 10/100B/100+
Hellmuth Ethernet LAN card under current: this card has some
Hellmuth on-board firmware, press CTRL-S on bootup and configure the
Hellmuth card as to (some of the options) what does it wake up.

Hellmuth Some months ago it was possible to let the machine fall to
Hellmuth sleep and when a packet arrived, it woke up (which was
Hellmuth exactly what i wanted) the machine (which is my home
Hellmuth workstation under current, which then slept over the day but
Hellmuth i was able to wake it up to access it from remote).

Hellmuth When this did not function anymore (APM-ACPI  fxp driver
Hellmuth changes), i tried to get docs from Intel on the chip but
Hellmuth failed completely.

My laptop has the fxp chipset onboard (a Fujitsu E6575) appears to
work flawlessly with wake-on-lan enabled in the bios.

I might add as an aside that FreeBSD running on the Fujitsu E series
is very sweet at this point.  APM, in particular suspend/unsuspend
work perfectly as does DVD and sound support.  Only the included modem
doesn't appear to work.  I should also comment that XFree86-3 doesn't
support the display where XFree86-4.1 does.

Dave.

-- 

|David Gilbert, Velocet Communications.   | Two things can only be |
|Mail:   [EMAIL PROTECTED] |  equal if and only if they |
|http://www.velocet.net/~dgilbert |   are precisely opposite.  |
=GLO

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

Re: FreeBSD on vmware

2001-11-15 Thread Garance A Drosihn


At 7:35 AM -0800 11/15/01, John Baldwin wrote:
On 15-Nov-01 Glenn Gombert wrote:

   Thanks for the tip Ian ...this works great! I have applied this patch
  to my desktop system ...and the FreeBSD Current kernel with this patch
  applied boots right up now...anyone else running Current under FreeBSD
  would fine it helpful to do as well

Perhaps we need an 'options VMWARE' that this could be triggered off of.

Sounds like a good idea.  But call it something like 'VMWARE_GUEST', so
it is less likely to be used by someone who wants to *run* vmware on
freebsd.  (and if we need some other kernel options for running vmware
on freebsd, those could be called 'VMWARE_HOST', or something).

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

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

Re: kern.vm.kmem.size

2001-11-15 Thread Eugene Grosbein


  So, how can I estimate needed value of kern.vm.kmem.size?
 
 How much ram do you have in the machine? On a 4.4-RC1 machine

I have 320M here.

 with 128MB of ram we don't have any problems getting dirhash
 to use almost all of it's 2MB:
 
 vfs.ufs.dirhash_maxmem: 2097152
 vfs.ufs.dirhash_mem: 2085797
 
 This is with the devault value for kern.vm.kmem.size. Maybe
 you could print the value your system is getting with:
 
 echo print vm_kmem_size |  gdb -k /kernel /dev/mem

You are absolutely right, it's using about 1/3 of RAM here 
(108875776 when I do not tune kern.vm.kmem.size). 
Hmm, my test seems to be incorrect somehow.
How can I see used amount of kernel malloc area?

Eugene Grosbein

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

_init execs in middle of code

2001-11-15 Thread PSI, Mike Smith


Does anyone know exactly what _init is? An nm of my executable lists:

080486a8 ? _init

It is the lowest numeric address (before _start and main) so I would
assume it is some sort of program initialization code. But when trying
to determine the cause of a kernel freeze (caused by my user app), I
found that _init is being called after quite a bit of code has been
executed.

I scanned every library known to man and of course all of my objects. I
cannot find any symbol reference to _init anywhere so I can only guess
it is set up by the linker. HELP! My kernel freezes (every 2nd/3rd
execution of the program) so I can't run the debugger on the kernel.

However, the freeze condition is very repeatable (happens what appears
to be the same point in the execution WHEN it happens) so if I can
figure out what _init is, I may have a chance to solve this.

Also if _init isn't supposed to be called during a program running, can
anyone give a clue as to what stupid programming error could cause this
to happen?


Thanks
Mike Smith (not THE Mike Smith)


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

RE: _init execs in middle of code

2001-11-15 Thread John Baldwin



On 15-Nov-01 PSI, Mike Smith wrote:
 Does anyone know exactly what _init is? An nm of my executable lists:
 
 080486a8 ? _init
 
 It is the lowest numeric address (before _start and main) so I would
 assume it is some sort of program initialization code. But when trying
 to determine the cause of a kernel freeze (caused by my user app), I
 found that _init is being called after quite a bit of code has been
 executed.
 
 I scanned every library known to man and of course all of my objects. I
 cannot find any symbol reference to _init anywhere so I can only guess
 it is set up by the linker. HELP! My kernel freezes (every 2nd/3rd
 execution of the program) so I can't run the debugger on the kernel.
 
 However, the freeze condition is very repeatable (happens what appears
 to be the same point in the execution WHEN it happens) so if I can
 figure out what _init is, I may have a chance to solve this.
 
 Also if _init isn't supposed to be called during a program running, can
 anyone give a clue as to what stupid programming error could cause this
 to happen?

IIRC, _init is when constructors for global variables are called (and _fini is
when destructors are called.)  It is magic behind the scenes generated by the
compiler and linker.

-- 

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-hackers in the body of the message

Re: _init execs in middle of code

2001-11-15 Thread Terry Lambert


PSI, Mike Smith wrote:
 
 Does anyone know exactly what _init is? An nm of my executable lists:
 
 080486a8 ? _init
 
 It is the lowest numeric address (before _start and main) so I would
 assume it is some sort of program initialization code. But when trying
 to determine the cause of a kernel freeze (caused by my user app), I
 found that _init is being called after quite a bit of code has been
 executed.
 
 I scanned every library known to man and of course all of my objects. I
 cannot find any symbol reference to _init anywhere so I can only guess
 it is set up by the linker. HELP! My kernel freezes (every 2nd/3rd
 execution of the program) so I can't run the debugger on the kernel.
 
 However, the freeze condition is very repeatable (happens what appears
 to be the same point in the execution WHEN it happens) so if I can
 figure out what _init is, I may have a chance to solve this.
 
 Also if _init isn't supposed to be called during a program running, can
 anyone give a clue as to what stupid programming error could cause this
 to happen?

_init is called by crt0.o.  It is used to, among other things,
initialize per thread exception stacks and instance statically
or globally declared classes, template base classes, and set up
pur virtual base classes for use.

It also executes anything else in the .entry code segment linker
set list (which is where this stuff is done).

See dumpobj.

If you want to run this in the debugger, then you should set a
breakpoint on _main (or just _init), and then single step the
machine instructions from there.

See the GCC web site for more detailed information.

-- Terry

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

has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)

2001-11-15 Thread Maxim Konovalov



[ forward to -hackers because of silence in -current ]

-- Forwarded message --
Date: Thu, 8 Nov 2001 17:35:17 +0300 (MSK)
From: Maxim Konovalov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: has 'options LOCKF_DEBUG' ever worked? (w/ patch)


Hello,

Seems 'options LOCKF_DEBUG' does not work at all.

How to repeat:

echo 'options LOCKF_DEBUG'  KERNELCONF,
recompile the kernel, install it, reboot,

# sysctl -w debug.lockf_debug=1
$ lockf -k /etc/passwd sleep 1

.. and got the panic:

Script started on Wed Nov  7 14:03:14 2001
miss# gdb -k /usr/obj/usr/src/sys/MISS/kernel.debug vmcore.4
GNU gdb 4.18
Copyright 1998 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 i386-unknown-freebsd...
IdlePTD 3858432
initial pcb at 303b40
panicstr: bdwrite: buffer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x1d
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc018f581
stack pointer   = 0x10:0xc66ebb40
frame pointer   = 0x10:0xc66ebb50
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 = 416 (lockf)
trap number = 12
panic: page fault

syncing disks... panic: bdwrite: buffer is not busy
Uptime: 6m54s

dumping to dev ad0s1b, offset 393600
dump ata0: resetting devices .. done
63 62 61 [CTRL-C to abort] 60 59 [CTRL-C to abort] 58 [CTRL-C to abort] 57 [CTRL-C to 
abort] 56 [CTRL-C to abort] 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 
36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 
6 5 4 3 2 1 0
---
#0  0xc0197d7e in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
476 }
(kgdb) bt
#0  0xc0197d7e in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:476
#1  0xc0df244c in ?? ()
#2  0xc0197b6b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:334
#3  0xc0197f9d in panic (fmt=0xc0299721 bdwrite: buffer is not busy)
at /usr/src/sys/kern/kern_shutdown.c:632
#4  0xc01c93e3 in bdwrite (bp=0xc213a91c) at /usr/src/sys/kern/vfs_bio.c:841
#5  0xc02286ad in ffs_update (vp=0xc65cb380, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:119
#6  0xc023539a in ffs_fsync (ap=0xc66eb9f4)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:292
#7  0xc02339aa in ffs_sync (mp=0xc0de5e00, waitfor=2, cred=0xc05ade00,
td=0xc031a8e4) at vnode_if.h:441
#8  0xc01d59c5 in sync (td=0xc031a8e4, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:662
#9  0xc0197770 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:244
#10 0xc0197f9d in panic (fmt=0xc02b129e %s)
at /usr/src/sys/kern/kern_shutdown.c:632
#11 0xc02747e3 in trap_fatal (frame=0xc66ebb00, eva=29)
at /usr/src/sys/i386/i386/trap.c:939
#12 0xc0274525 in trap_pfault (frame=0xc66ebb00, usermode=0, eva=29)
at /usr/src/sys/i386/i386/trap.c:851
#13 0xc0273f37 in trap (frame={tf_fs = -1071841256, tf_es = -965869552,
  tf_ds = 16, tf_edi = 0, tf_esi = 0, tf_ebp = -965821616,
  tf_isp = -965821652, tf_ebx = -1058144640, tf_edx = -1071033256,
  tf_ecx = -1069469696, tf_eax = 1, tf_trapno = 12, tf_err = 0,
  tf_eip = -1072106111, tf_cs = 8, tf_eflags = 66118,
  tf_esp = -1071033241, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:403
#14 0xc0266488 in alltraps_with_regs_pushed ()
#15 0xc018ea2a in lf_setlock (lock=0xc0edfe80)
at /usr/src/sys/kern/kern_lockf.c:211
#16 0xc018e9c3 in lf_advlock (ap=0xc66ebc04, head=0xc0edd93c, size=0)
at /usr/src/sys/kern/kern_lockf.c:176
#17 0xc023d30e in ufs_advlock (ap=0xc66ebc04)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2190
#18 0xc023d7f9 in ufs_vnoperate (ap=0xc66ebc04)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2658
#19 0xc01d64e3 in open (td=0xc6691e04, uap=0xc66ebd20) at vnode_if.h:843
#20 0xc0274c64 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
  tf_edi = -1, tf_esi = -1077938004, tf_ebp = -1077938176,
  tf_isp = -965821068, tf_ebx = -1077937786, tf_edx = -1077938012,
  tf_ecx = 672100864, tf_eax = 5, tf_trapno = 12, tf_err = 2,
  tf_eip = 671764168, tf_cs = 31, tf_eflags = 663, tf_esp = -1077938220,
  tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1127
#21 0xc02664bd in syscall_with_err_pushed ()
#22 0x8048ae2 in ?? ()
#23 0x80488f1 in ?? ()
(kgdb) quit    p   quit
miss# exit
exit

Script done on Wed Nov  7 14:04:38 2001

It panics because of if_inode is not initiliazed:

/sys/kern/kern_lockf.c:1.25:153

/*  lock-lf_inode = ip; */ /* XXX JH */

I have no idea what ``JH'' means, the comment appeared in 1.10.

The patch against kern_lockf.c:1.38

Index:

Re: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)

2001-11-15 Thread Alfred Perlstein


Yes I saw this, I have no idea what 'JH' stands for either that's why
I left it as is.

The problem is that VTOI is ufs specific, this fix will break
LOCKF_DEBUG for all other FS's other than UFS because it casts
the vnode-data ptr to struct inode *.

So your fix is broken.

Please just fix lf_print to not deref the inode ptr in the struct.

-Alfred

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

Re: kernel malloc questions...

2001-11-15 Thread Alfred Perlstein


* Chris Ptacek [EMAIL PROTECTED] [05 15:22] wrote:
 Hey all, I have a couple questions about kernel mallocs.
 
 I am trying to malloc a large amount of memory for a KLD during load and the
 malloc keeps failing.  I am trying to malloc 64-128MB for a memory pool for
 a project I am working on.  My system has 196MB of memory and the KLD is
 loaded at startup so I am relativly sure that I have enough memory to
 satisfy the request.

You're probably incorrect.  I know malloc looks easy, but what you
want to use is the underlying mechanisms that malloc uses, vm_alloc
or whatnot.

-- 
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using 1970s technology,
 start asking why software is ignoring 30 years of accumulated wisdom.'
   http://www.morons.org/rants/gpl-harmful.php3

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

RE: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)

2001-11-15 Thread John Baldwin



On 15-Nov-01 Maxim Konovalov wrote:
 It panics because of if_inode is not initiliazed:
 
 /sys/kern/kern_lockf.c:1.25:153
 
 /*  lock-lf_inode = ip; */ /* XXX JH */
 
 I have no idea what ``JH'' means, the comment appeared in 1.10.

revision 1.10
date: 1997/02/10 02:09:36;  author: dyson;  state: Exp;  lines: +53 -68
This is the kernel Lite/2 commit.  There are some requisite userland
changes, so don't expect to be able to run the kernel as-is (very well)
without the appropriate Lite/2 userland changes.

The system boots and can mount UFS filesystems.

Untested: ext2fs, msdosfs, NFS
Known problems: Incorrect Berkeley ID strings in some files.
Mount_std mounts will not work until the getfsent
library routine is changed.

Reviewed by:various people
Submitted by:   Jeffery Hsu [EMAIL PROTECTED]

Obviously the 'JH' seems to refer to [EMAIL PROTECTED]  He might have more
details on why this change was made. It seems that it has been broken for 4.75
years at this point. :)

I have no objections to the patch except that the concept of an inode is not
valid on all file systems, which is why that may be commented out in the first
place.

-- 

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-hackers in the body of the message

Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflags creash (fixed!)]

2001-11-15 Thread Maxim Sobolev


On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
 
 I learned about this by reading through some of the -hackers archives.
 One person complained of similar errors trying to get xine to work on
 FreeBSD.  Removing the MMX detection code fixed it.  I remembered libpng
 also used MMX, so I removed the pnggccrd.c source, and voila!
 
 Based on core dumps, strace output, and a lot of code surfing, this makes
 sense to me.  Basically, any png-dependent app's thread that runs longer
 than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
 happens, things context switch.  eflags must have been corrupted by the
 MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
 well.  Here's what strace looks like when balsa tries to read a 33 MB
 mailbox:
 
 74202 sigreturn(0x81f2c64
 
 When this happens, strace politely dies with a bus error.
 
 Thanks for testing this, Maxim.  Hopefully someone can find the problem
 and fix it for good.

That explains... After a quick glance at png code I found that
the only place where EFLAGS is altered is CPUID code, where
the library flips bit 21 of EFLAGS in order to ensure that the
CPUID instruction is supported (otherwise it will get SIGILL
on older processors). Unfortunately, for some reason FreeBSB
kernel considers bit 21 of EFLAGS as one that should not be
altered in the user mode, thus making it illegal to use standard
user-mode processor-detection routines based around that bit.
AFAIK, it is a bug in FreeBSD, because there is actually nothing
wrong with altering bit 21 in the user mode - it doesn't have
any side effects and pretty much any of the currently available
on the i386 OSes allows it.

Therefore, I would like to ask you to test attached patch and
if it works and there are no other objections I would like to
commit it shortly. To test the patch, you need to recompile
kernel with patch applied, reboot, recompile/reinstall png with
MXX support turned on and try to run Nautilus. Please let me know
if it helped or not.

Thanks!

-Maxim


psl.h.diff
Description: Binary data

RE: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

2001-11-15 Thread John Baldwin



On 15-Nov-01 Maxim Sobolev wrote:
 That explains... After a quick glance at png code I found that
 the only place where EFLAGS is altered is CPUID code, where
 the library flips bit 21 of EFLAGS in order to ensure that the
 CPUID instruction is supported (otherwise it will get SIGILL
 on older processors). Unfortunately, for some reason FreeBSB
 kernel considers bit 21 of EFLAGS as one that should not be
 altered in the user mode, thus making it illegal to use standard
 user-mode processor-detection routines based around that bit.
 AFAIK, it is a bug in FreeBSD, because there is actually nothing
 wrong with altering bit 21 in the user mode - it doesn't have
 any side effects and pretty much any of the currently available
 on the i386 OSes allows it.

Agreed, patch looks good to me.

-- 

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-hackers in the body of the message

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflagscreash (fixed!)]

2001-11-15 Thread Joe Clarke




On Thu, 15 Nov 2001, Maxim Sobolev wrote:

 On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
 
  I learned about this by reading through some of the -hackers archives.
  One person complained of similar errors trying to get xine to work on
  FreeBSD.  Removing the MMX detection code fixed it.  I remembered libpng
  also used MMX, so I removed the pnggccrd.c source, and voila!
 
  Based on core dumps, strace output, and a lot of code surfing, this makes
  sense to me.  Basically, any png-dependent app's thread that runs longer
  than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
  happens, things context switch.  eflags must have been corrupted by the
  MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
  well.  Here's what strace looks like when balsa tries to read a 33 MB
  mailbox:
 
  74202 sigreturn(0x81f2c64
 
  When this happens, strace politely dies with a bus error.
 
  Thanks for testing this, Maxim.  Hopefully someone can find the problem
  and fix it for good.

 That explains... After a quick glance at png code I found that
 the only place where EFLAGS is altered is CPUID code, where
 the library flips bit 21 of EFLAGS in order to ensure that the
 CPUID instruction is supported (otherwise it will get SIGILL
 on older processors). Unfortunately, for some reason FreeBSB
 kernel considers bit 21 of EFLAGS as one that should not be
 altered in the user mode, thus making it illegal to use standard
 user-mode processor-detection routines based around that bit.
 AFAIK, it is a bug in FreeBSD, because there is actually nothing
 wrong with altering bit 21 in the user mode - it doesn't have
 any side effects and pretty much any of the currently available
 on the i386 OSes allows it.

 Therefore, I would like to ask you to test attached patch and
 if it works and there are no other objections I would like to
 commit it shortly. To test the patch, you need to recompile
 kernel with patch applied, reboot, recompile/reinstall png with
 MXX support turned on and try to run Nautilus. Please let me know
 if it helped or not.

Works like a champ!  Thanks a lot for taking this to the next step.  It's
really good to have full Gnome functionality.

Joe


 Thanks!

 -Maxim


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

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflags creash (fixed!)]

2001-11-15 Thread Daniel Eischen


On Thu, 15 Nov 2001, Maxim Sobolev wrote:
 On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
  
  I learned about this by reading through some of the -hackers archives.
  One person complained of similar errors trying to get xine to work on
  FreeBSD.  Removing the MMX detection code fixed it.  I remembered libpng
  also used MMX, so I removed the pnggccrd.c source, and voila!
  
  Based on core dumps, strace output, and a lot of code surfing, this makes
  sense to me.  Basically, any png-dependent app's thread that runs longer
  than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
  happens, things context switch.  eflags must have been corrupted by the
  MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
  well.  Here's what strace looks like when balsa tries to read a 33 MB
  mailbox:
  
  74202 sigreturn(0x81f2c64
  
  When this happens, strace politely dies with a bus error.
  
  Thanks for testing this, Maxim.  Hopefully someone can find the problem
  and fix it for good.
 
 That explains... After a quick glance at png code I found that
 the only place where EFLAGS is altered is CPUID code, where
 the library flips bit 21 of EFLAGS in order to ensure that the
 CPUID instruction is supported (otherwise it will get SIGILL
 on older processors). Unfortunately, for some reason FreeBSB

Does it need to keep bit 21 of EFLAGS flipped, or can libpng
set it back and keep knowledge that CPUID is supported?  Or
does that bit need to remain set for CPUID to work?

 kernel considers bit 21 of EFLAGS as one that should not be
 altered in the user mode, thus making it illegal to use standard
 user-mode processor-detection routines based around that bit.
 AFAIK, it is a bug in FreeBSD, because there is actually nothing
 wrong with altering bit 21 in the user mode - it doesn't have
 any side effects and pretty much any of the currently available
 on the i386 OSes allows it.
 
 Therefore, I would like to ask you to test attached patch and
 if it works and there are no other objections I would like to
 commit it shortly. To test the patch, you need to recompile
 kernel with patch applied, reboot, recompile/reinstall png with
 MXX support turned on and try to run Nautilus. Please let me know
 if it helped or not.

If at all possible, a fix should be committed that wouldn't
necessitate a new kernel be built for -stable.

-- 
Dan Eischen

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

Re: kernel malloc questions...

2001-11-15 Thread Terry Lambert


Chris Ptacek wrote:
 I am trying to malloc a large amount of memory for a KLD during load and the
 malloc keeps failing.  I am trying to malloc 64-128MB for a memory pool for
 a project I am working on.  My system has 196MB of memory and the KLD is
 loaded at startup so I am relativly sure that I have enough memory to
 satisfy the request.
 
 I guess the questions are:
 
 Is there a limit to the amount of memory the kernel (including
 modules) can malloc?

Yes.  There are two limits.  One is based on the amount of mappings
available, which limits your total swap plus physical memory that
you can allocate.  The second one is 1G, because that the size of
the KernelVirtual Address space.


 If there is how do I change this amount?

The kernel virtual address space can be increased.  The handbook
give almost all (but not quite) the information needed.  See the
-current list archives.


 I am currently using M_NOWAIT, would using M_WAITOK be better?

M_NOWAIT means that you are not permitting it to sleep; this
means that you are willing to accept a failure, rather than
have the process on whose behalf the call is being made put
to sleep.  You say it's a KLD, but fail to tell us if it is a
device driver in the module.  I'll assume that it is.  Then
the answer is that you can't sleep unless you create a kernel
process to use as a sleep context.


 Would this end up hanging my system in this case?

It depends on your usage; see above.  M_WAITOK is supposed to
wait until the memory is available; but in fact, it does not
wait forever, like you would want.  If it fails after a number
of retries, it gives up.  This is a semantic change that came
in early in the 4.x branch,  It was never really justified to
my satisfaction, other than someone had a wait case that failed
once in a while, and didn't want to understand the code fully
enough to fix it.  So no matter how you call it, you have to be
prepared for a failure.

Knowing why it fails would probably help you: the failure can
only occur if it traverses the map looking for a large enough
space and can't find it.


 Would I be better off mallocing many smaller buffers into a
 memory pool (64 1MB buffers)?

It depends on your usage.  If the memory is necessary to be
contiguous, then you could do worse than to follow Alfred's
advice.  In any case, if you can do it as smaller chunks, you
will get better utilization of the kernel memory map, and will
be more likely to not need a large contiguous region.


-- Terry

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

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

2001-11-15 Thread John Baldwin



On 15-Nov-01 Daniel Eischen wrote:
 On Thu, 15 Nov 2001, Maxim Sobolev wrote:
 On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
  
  I learned about this by reading through some of the -hackers archives.
  One person complained of similar errors trying to get xine to work on
  FreeBSD.  Removing the MMX detection code fixed it.  I remembered libpng
  also used MMX, so I removed the pnggccrd.c source, and voila!
  
  Based on core dumps, strace output, and a lot of code surfing, this makes
  sense to me.  Basically, any png-dependent app's thread that runs longer
  than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
  happens, things context switch.  eflags must have been corrupted by the
  MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
  well.  Here's what strace looks like when balsa tries to read a 33 MB
  mailbox:
  
  74202 sigreturn(0x81f2c64
  
  When this happens, strace politely dies with a bus error.
  
  Thanks for testing this, Maxim.  Hopefully someone can find the problem
  and fix it for good.
 
 That explains... After a quick glance at png code I found that
 the only place where EFLAGS is altered is CPUID code, where
 the library flips bit 21 of EFLAGS in order to ensure that the
 CPUID instruction is supported (otherwise it will get SIGILL
 on older processors). Unfortunately, for some reason FreeBSB
 
 Does it need to keep bit 21 of EFLAGS flipped, or can libpng
 set it back and keep knowledge that CPUID is supported?  Or
 does that bit need to remain set for CPUID to work?

It needs to be able to change it.  If you can change the value of the bit (done
by pushf ; pop %eax ; mov %eax,%ebx ; xor $PSL_ID,%eax ; push %eax ; popf ;
pushf ; pop %eax ; compare bit PSL_ID of eax ebx to see if they match).
The problem is if a signal comes in during the middle of that bit toggling due
to a profiling timer.  I think the problem may be that it uses a sequence that
leaves the bit set, thus the kernel freaks out thinking that the user has
changed a kernel only flag.  The solution is Maxim's patch to make the kernel
not care about the flag (which it shouldn't since cpuid is not a privileged
instruction).

 If at all possible, a fix should be committed that wouldn't
 necessitate a new kernel be built for -stable.

Perhaps if you patched libpng to block all signals and changed the code to add
a pushf/popf around the entire sequence to preserve the PSL_ID flag.  You
would need to do this for xien and other apps that attempt to use cpuid as well.

Fixing the kernel is much easier as Maxim's patch shows.

-- 

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-hackers in the body of the message

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflags creash (fixed!)]

2001-11-15 Thread Maxim Sobolev


On Thu, 15 Nov 2001 17:41:32 -0500 (EST), Daniel Eischen wrote:
 On Thu, 15 Nov 2001, Maxim Sobolev wrote:
  On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
   
   I learned about this by reading through some of the -hackers archives.
   One person complained of similar errors trying to get xine to work on
   FreeBSD.  Removing the MMX detection code fixed it.  I remembered libpng
   also used MMX, so I removed the pnggccrd.c source, and voila!
   
   Based on core dumps, strace output, and a lot of code surfing, this makes
   sense to me.  Basically, any png-dependent app's thread that runs longer
   than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
   happens, things context switch.  eflags must have been corrupted by the
   MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
   well.  Here's what strace looks like when balsa tries to read a 33 MB
   mailbox:
   
   74202 sigreturn(0x81f2c64
   
   When this happens, strace politely dies with a bus error.
   
   Thanks for testing this, Maxim.  Hopefully someone can find the problem
   and fix it for good.
  
  That explains... After a quick glance at png code I found that
  the only place where EFLAGS is altered is CPUID code, where
  the library flips bit 21 of EFLAGS in order to ensure that the
  CPUID instruction is supported (otherwise it will get SIGILL
  on older processors). Unfortunately, for some reason FreeBSB
 
 Does it need to keep bit 21 of EFLAGS flipped, or can libpng
 set it back and keep knowledge that CPUID is supported?  Or
 does that bit need to remain set for CPUID to work?

No it doesn't need it to be in any specific state. The only
knowelege a program gains from the bit 21 is that its state
could be changed, which means that CPUID instruction is
supported. Unfortunately original libpng doesn't bother to
set the state of the bit back, which exposed this problem.

 If at all possible, a fix should be committed that wouldn't
 necessitate a new kernel be built for -stable.

Yes, I was also thinking about that. I've committed a patch,
which restores state of the bit 21 as soon as possible. There
is still a chance that the program will get a signal during
that time, but this change is rather slim. The unsafe piece
of code in question looks like:

popfl   -load eflags with bit 21 flipped
pushfl  -save resulting eflags
+   popl %%eax  -load resulting eflags into eax
+   pushl %%ecx -save original eflags
popfl   -restore original eflags

Of course, it is possible to either mask all signals during
detection period, or rip out detection code based around
eflags and replace it with SIGILL handler, but this will
cannibalize on speed improvement from MMX optimisations
because of the additonal overhead associated with doing
syscall necessary to set-up signal handler or signal mask.
In any case, tomorrow I will test this workaround
extensively, and if it appears that it is not sufficient
to prevent `sigreturn: eflags...' errors, then I'll just
disable MMX code in the libpng.

-Maxim

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

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

2001-11-15 Thread Daniel Eischen


On Thu, 15 Nov 2001, John Baldwin wrote:
 On 15-Nov-01 Daniel Eischen wrote:
  On Thu, 15 Nov 2001, Maxim Sobolev wrote:
  On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
   
   I learned about this by reading through some of the -hackers archives.
   One person complained of similar errors trying to get xine to work on
   FreeBSD.  Removing the MMX detection code fixed it.  I remembered libpng
   also used MMX, so I removed the pnggccrd.c source, and voila!
   
   Based on core dumps, strace output, and a lot of code surfing, this makes
   sense to me.  Basically, any png-dependent app's thread that runs longer
   than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
   happens, things context switch.  eflags must have been corrupted by the
   MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
   well.  Here's what strace looks like when balsa tries to read a 33 MB
   mailbox:
   
   74202 sigreturn(0x81f2c64
   
   When this happens, strace politely dies with a bus error.
   
   Thanks for testing this, Maxim.  Hopefully someone can find the problem
   and fix it for good.
  
  That explains... After a quick glance at png code I found that
  the only place where EFLAGS is altered is CPUID code, where
  the library flips bit 21 of EFLAGS in order to ensure that the
  CPUID instruction is supported (otherwise it will get SIGILL
  on older processors). Unfortunately, for some reason FreeBSB
  
  Does it need to keep bit 21 of EFLAGS flipped, or can libpng
  set it back and keep knowledge that CPUID is supported?  Or
  does that bit need to remain set for CPUID to work?
 
 It needs to be able to change it.  If you can change the value of the bit (done
 by pushf ; pop %eax ; mov %eax,%ebx ; xor $PSL_ID,%eax ; push %eax ; popf ;
 pushf ; pop %eax ; compare bit PSL_ID of eax ebx to see if they match).
 The problem is if a signal comes in during the middle of that bit toggling due
 to a profiling timer.  I think the problem may be that it uses a sequence that
 leaves the bit set, thus the kernel freaks out thinking that the user has
 changed a kernel only flag.  The solution is Maxim's patch to make the kernel
 not care about the flag (which it shouldn't since cpuid is not a privileged
 instruction).

I just thought perhaps libpng could do something like:

static int  init_done = 0;
static int  cpuid_supported = 0;

...

if (init_done == 0) {
block_all_sigs();
cpuid_supported = check_cpuid();
init_done = 1;
unblock_sigs();
}

But if it always needs to change the bit, I guess the above doesn't help.

-- 
Dan Eischen

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

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

2001-11-15 Thread John Baldwin



On 16-Nov-01 Daniel Eischen wrote:
 On Thu, 15 Nov 2001, John Baldwin wrote:
 On 15-Nov-01 Daniel Eischen wrote:
  On Thu, 15 Nov 2001, Maxim Sobolev wrote:
  On Thu, 15 Nov 2001 14:56:31 -0500 (EST), Joe Clarke wrote:
   
   I learned about this by reading through some of the -hackers archives.
   One person complained of similar errors trying to get xine to work on
   FreeBSD.  Removing the MMX detection code fixed it.  I remembered
   libpng
   also used MMX, so I removed the pnggccrd.c source, and voila!
   
   Based on core dumps, strace output, and a lot of code surfing, this
   makes
   sense to me.  Basically, any png-dependent app's thread that runs
   longer
   than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
   happens, things context switch.  eflags must have been corrupted by the
   MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
   well.  Here's what strace looks like when balsa tries to read a 33 MB
   mailbox:
   
   74202 sigreturn(0x81f2c64
   
   When this happens, strace politely dies with a bus error.
   
   Thanks for testing this, Maxim.  Hopefully someone can find the problem
   and fix it for good.
  
  That explains... After a quick glance at png code I found that
  the only place where EFLAGS is altered is CPUID code, where
  the library flips bit 21 of EFLAGS in order to ensure that the
  CPUID instruction is supported (otherwise it will get SIGILL
  on older processors). Unfortunately, for some reason FreeBSB
  
  Does it need to keep bit 21 of EFLAGS flipped, or can libpng
  set it back and keep knowledge that CPUID is supported?  Or
  does that bit need to remain set for CPUID to work?
 
 It needs to be able to change it.  If you can change the value of the bit
 (done
 by pushf ; pop %eax ; mov %eax,%ebx ; xor $PSL_ID,%eax ; push %eax ; popf ;
 pushf ; pop %eax ; compare bit PSL_ID of eax ebx to see if they match).
 The problem is if a signal comes in during the middle of that bit toggling
 due
 to a profiling timer.  I think the problem may be that it uses a sequence
 that
 leaves the bit set, thus the kernel freaks out thinking that the user has
 changed a kernel only flag.  The solution is Maxim's patch to make the
 kernel
 not care about the flag (which it shouldn't since cpuid is not a privileged
 instruction).
 
 I just thought perhaps libpng could do something like:
 
   static int  init_done = 0;
   static int  cpuid_supported = 0;
 
   ...
 
   if (init_done == 0) {
   block_all_sigs();
   cpuid_supported = check_cpuid();
   init_done = 1;
   unblock_sigs();
   }
 
 But if it always needs to change the bit, I guess the above doesn't help.

No, that's correct.  The problem is the check_cpuid() function left the state
of the PSL_ID flag bit changed. :)  So you need to change the check_cpuid() to
include a wrapper to save/restore the flags.  Maxim just committed a change to
do this.  I'm not sure if he included the signal blocking though.

-- 

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-hackers in the body of the message

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

2001-11-15 Thread Warner Losh


I'm also seeing this in my X server...

Warner

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

ÖÐ¹úÊ¯ÓÍºÍÊ¯ÓÍ»¯¹¤Éè±¸¹¤ÒµÐ»á

2001-11-15 Thread ÖÐÃ³


»¶ Ó ²Î ¹Û
 
 2001ÖÐ¹ú£¨ÉÏº££©¹ú¼ÊÊ¯ÓÍ¼°Ê¯»¯¼¼ÊõÉè±¸Õ¹ÀÀ»á

  Í¬ÆÚ¾Ù°ì£º2001ÉÏº£¹ú¼Ê»¯¹¤¼¼ÊõÉè±¸Õ¹ÀÀ»á
2001ÉÏº£¹ú¼ÊÆøÌå¼¼ÊõÉè±¸Õ¹ÀÀ»á

ÓÉÖÐ¹úÊ¯ÓÍºÍÊ¯ÓÍ»¯¹¤Éè±¸¹¤ÒµÐ»á¡¢ÉÏº£ÊÐ»úÐµ¹¤³ÌÑ§»á¼°ÉÏº£ÖÐÃ³Õ¹ÀÀ
·þÎñÓÐÏÞ¹«Ë¾µÈµ¥Î»¹²Í¬¾Ù°ìµÄ2001 ÖÐ¹ú£¨ÉÏº££©¹ú¼ÊÊ¯ÓÍ¼°Ê¯»¯¼¼ÊõÉè±¸Õ¹
ÀÀ»á½«ÓÚ2001Äê11ÔÂ29ÈÕ-12ÔÂ1ÈÕÔÚÉÏº£¹â´ó»áÕ¹ÖÐÐÄÂ¡ÖØ¾Ù°ì¡£ ±¾´ÎÕ¹»áÎü
ÒýÁËÀ´×Ô¹úÄÚÍâ250¼Ò³§ÉÌ²ÎÕ¹£¬ »ã¾ÛÖÚ¶à¹úÄÚÍâÖøÃû³§ÉÌµÄ×îÐÂ¼¼ÊõÓëÉè±¸ ¡£
²¢¾Ù°ìÏà¹Ø±¨¸æ»á¼°¼¼Êõ½»Á÷»á¡£

ÎÒÃÇ³ÏÑûÄã½ìÊ±¹âÁÙÕ¹»á²Î¹Û¡¢½»Á÷¡£

ÏêÇéÇë²éÑ¯£ºÉÏº£ÖÐÃ³Õ¹ÀÀ·þÎñÓÐÏÞ¹«Ë¾  

ÉÏº£ÊÐäîÏªÂ·251Åª5ºÅÂ¥20F  µç »°£º021-54641713 54641743 
   ´« Õæ£º021-64942305 
   E-mail:[EMAIL PROTECTED]
   http:www.zhongmao.com.cn

 ¼¼Êõ½»Á÷Óë±¨¸æ»á

Ö÷  Ìâ£ºÐýÁ÷·ÖÀë¼¼ÊõÔÚÊ¯ÓÍ¡¢»¯¹¤¹¤ÒµÖÐµÄÓ¦ÓÃ
±¨¸æÈË£º½ÌÓý²¿½ÄÏ´óÑ§·ÖÀë¹¤³ÌÑÐ¾¿Ëù
Ô¬»ÝÐÂ½ÌÊÚ
Ê±  ¼ä£º2001Äê11ÔÂ29ÈÕÉÏÎç10£º30-11£º30
µØ  µã£ºÉÏº£¹â´ó»áÕ¹ÖÐÐÄÎ÷¹Ý¶þºÅ»áÒéÊÒ

Ö÷  Ìâ£º¹ØÓÚÎÒ¹úÊ¯ÓÍ×ê²É¼¼Êõ×°±¸·¢Õ¹µÄÈô¸É¶Ô²ß
±¨¸æÈË£ºÊ¯ÓÍ´óÑ§ ÕÅËÃÎ°½ÌÊÚ
Ê±  ¼ä£º2001Äê11ÔÂ29ÈÕÏÂÎç13£º30-15£º30
µØ  µã£ºÉÏº£¹â´ó»áÕ¹ÖÐÐÄÎ÷¹Ý¶þºÅ»áÒéÊÒ

Ö÷  Ìâ£ºÊ®ÎåÆÚ¼äÊ¯»¯¹¤ÒµµÄ·¢Õ¹¼°Æä¶Ô×°±¸µÄÐèÇó
±¨¸æÈË£ºÖÐ¹úÊ¯ÓÍ»¯¹¤¼¯ÍÅ¹«Ë¾×ÉÑ¯¹«Ë¾ ³ÂÔÊÖÐ½ÌÊÚ¼¶¸ß¹¤
Ê±  ¼ä£º2001Äê11ÔÂ30ÈÕÉÏÎç10£º00-12£º00
µØ  µã£ºÉÏº£¹â´ó»áÕ¹ÖÐÐÄÎ÷¹Ý¶þºÅ»áÒéÊÒ

Ö÷  Ìâ£ºÈ«Çò¹¤ÒµÆøÌåÊÐ³¡µÄ·¢Õ¹Ç÷Ïò
Ê±  ¼ä£º2001Äê11ÔÂ30ÈÕÉÏÎç10£º00-11£º30
µØ  µã£ºÉÏº£¹â´ó»áÕ¹ÖÐÐÄÎ÷¹ÝËÄºÅ»áÒéÊÒ
±¨¸æÈË£ºJohn Racquet ÏÈÉú
 
Ö÷  Ìâ£º¹¤Òµ´¿Ë® ³¬´¿Ë®ÖÆÔì
Ê±  ¼ä£º2001Äê11ÔÂ30ÈÕÏÂÎç13£º30-15£º00
µØ  µã£ºÉÏº£¹â´ó»áÕ¹ÖÐÐÄÎ÷¹ÝËÄºÅ»áÒéÊÒ
±¨¸æÈË£ºº¼ÖÝ£¨»ð¾æ£©Î÷¶·ÃÅÄ¤¹¤ÒµÓÐÏÞ¹«Ë¾ ÐìÈÙ°²×Ü¾Àí
 

²¿·ÖÕ¹ÉÌÃûµ¥

Ó¢¹úººÄ·ÎÖË¹°×Á¦ÊË-Ä¦ºà¹«Ë¾   µÂ¹úÈü¶àÀûË¹ÓÐÏÞ¹«Ë¾
Louisiana Chemical Equipment Co L.L.C Î÷ÃÅ×ÓÕæ¿Õ±ÃÑ¹Ëõ»úÓÐÏÞ¹«Ë¾
°¢Ä·Ë¹×³.ÔÆÂ·½ÚÄÜÉè±¸ÓÐÏÞ¹«Ë¾ º¼ÖÝ²¼ÀÊµÍÎÂÉè±¸ÓÐÏÞ¹«Ë¾
ÒËÐËÌ¨ÐË»·±£ÓÐÏÞ¹«Ë¾  º¼ÖÝ£¨»ð¾æ£©Î÷¶·ÃÅÄ¤¹¤Òµ¹«Ë¾
º«¹ú£¨Öê£©ÐÅÓÑµç×ÓÉÏº£¿Æ´ïÊµÒµÓÐÏÞ¹«Ë¾
ÉÏº£Â¡Ç¿¼ì²âÒÇÆ÷Éè±¸ÓÐÏÞ¹«Ë¾  Ì¨ÍåÊËÆôÓÐÏÞ¹«Ë¾
ÄÏÑô·À±¬¼¯ÍÅÓÐÏÞ¹«Ë¾  ÉýÑôÆóÒµ£¨¹É·Ý£©¹«Ë¾
¸£ÖÝ·§ÃÅ×Ü³§  ÎÂÖÝÊÐÀûÆÕ×Ô¿ØÉè±¸ÓÐÏÞ¹«Ë¾
ÉÏº£´¬±õÖÆÒ©·ÛËéÉè±¸³§ÄÏÍ¨É½½£Ê¯Ä«Éè±¸ÓÐÏÞ¹«Ë¾
ÉÏº£°Í°²Ë®´¦Àí¹¤³ÌÓÐÏÞ¹«Ë¾Ã·ÌØÀÕ-ÍÐÀû¶à³£ÖÝºâÆ÷¹«Ë¾
ÀïÆäÀÖÃ³Ò×£¨ÉÏº££©ÓÐÏÞ¹«Ë¾É½Î÷ÐË°²»¯Ñ§¹¤Òµ£¨¼¯ÍÅ£©¹«Ë¾
Îâ½ÊÐ¹ÌÁ¦ÕÍ¹ÜÆ÷ÓÐÏÞ¹«Ë¾  ÉÏº£Éê·½ÈÈÄÜ»úÐµÉè±¸ÓÐÏÞ¹«Ë¾
Õã½Ê¡ÎÂÁëÊÐÉñ¹âÈÈÄÜÉè±¸ÓÐÏÞ¹«Ë¾  ÉÏº£·ç¸ùÑ¹Ëõ»úÓÐÏÞ¹«Ë¾
Ìì½ò±ÃÒµ»úÐµ¼¯ÍÅÓÐÏÞ¹«Ë¾  ÉÏº£¿É¹ó¹ÌÌ¬Àë×Óµ¼Ìå¹«Ë¾
Äþ²¨ÌìÉúÃÜ·â¼þÓÐÏÞ¹«Ë¾´ÈÏªºãÁ¦Í¬²½´øÂÖÓÐÏÞ¹«Ë¾
º¼ÖÝÐËÔ´¹ýÂË»úÓÐÏÞ¹«Ë¾ºÓÄÏ¿ÆÔ´Ê¯ÓÍ¼¼Êõ¿ª·¢¹«Ë¾
ËÄ´¨ÑÇÁªÉúÎï»¯¹¤ÑÐ¾¿ËùÓª¿ÚÊÐ¹Ü¼þ¹¤Òµ¹«Ë¾
°°É½ÊÐ¿Æ³Ï×Ô¶¯»¯ÏµÍ³ÓÐÏÞ¹«Ë¾  ¹ãÖÝÊÐ²©Ê¿Âü»úµçÓÐÏÞ¹«Ë¾
±±¾©¶«·½Ê¥Â¡´ï¿ÆÃ³ÓÐÏÞ¹«Ë¾Îâ½ÝÚæÚÊ¯ÓÍ»¯¹¤³§
ËÕÖÝÅ¦Íþ»úÐµÓÐÏÞ¹«Ë¾  ÉÏº£½ðÄÉ²¨¿Æ¼¼·¢Õ¹ÓÐÏÞ¹«Ë¾
ÉÏº£·ÉºÍ»úÐµÓÐÏÞ¹«Ë¾  ÉÏº£Äá¿ÉÄá±ÃÒµÓÐÏÞ¹«Ë¾
Õã½·á»ªÇá»ú·§ÃÅ³§É½¶«Ê¡Î«·»Éú½¨»úÐµ³§£¨¼¯ÍÅ£©
½ËÕÊ¡½ÒõÊÐÊ¯ÓÍ»¯¹¤Éè±¸ÓÐÏÞ¹«Ë¾  ÎÂÖÝÊÐ·úËÜÉè±¸ÖÆÔì³§
Õã½ÓÓÀû¹¤³ÌËÜÁÏ¹ÜµÀ×Ü³§  ÉîÛÚÊÐÌØ°²µç×ÓÓÐÏÞ¹«Ë¾
²ý»Ý£¨Ìì½ò£©¹ú¼ÊÃ³Ò×ÓÐÏÞ¹«Ë¾  Õã½Ê¡ÁÙº£ÊÐ»úÉ¸³§
ÉÏº£ÁøÓª»úÐµ³§ÂÞ´ïÀ³¿ËË¹·§ÃÅ£¨ÉÏº££©ÓÐÏÞ¹«Ë¾
±±¾©¾Ó°²Èðº«¿Æ¼¼·¢Õ¹ÓÐÏÞ¹«Ë¾  º¼ÖÝÄÏ·½ÌØÖÖ±Ã³§
³É¶¼°²¿ÉÐÅµç×ÓÓÐÏÞ¹«Ë¾¹þ¶û±õÁëÄÏ¹ÜµÀÁ¬½ÓÆ÷ÓÐÏÞ¹«Ë¾
±±¾©Ôó»ª¿µÒ«¼¼Êõ·¢Õ¹ÓÐÏÞ¹«Ë¾  Æ½ºþÊÐ³¿ÈËÈ¼ÆøÉè±¸ÓÐÏÞ¹«Ë¾
°²»ÕÖÐ¿ÆÖÇÄÜ¸ß¼¼ÊõÓÐÏÞÔðÈÎ¹«Ë¾Õã½´ºêÍ¼¯ÍÅÓÐÏÞ¹«Ë¾
µÂ¸ß½àÇå½àÉè±¸ÓÐÏÞ¹«Ë¾±±¾©¸ñÁÖ²©ÄÉÉÌÃ³ÓÐÏÞ¹«Ë¾
Õã½Ê¡ÓÀ¿µÊÐÐÂÁúÒÇ±íÓÐÏÞ¹«Ë¾  ÎÞÎýÊÐÇ®ÊÏ¿Æ¼¼¿ª·¢ÓÐÏÞ¹«Ë¾
³É¶¼ºÀË¹µç×ÓÌ½²â¼¼ÊõÓÐÏÞ¹«Ë¾  ¸Û»ª»ÔÐÅ¹¤³ÌËÜÁÏ£¨ÖÐÉ½£©¹«Ë¾  
Ê¯¼Ò×¯ÊÐºà´ïîÑ¹ýÂËÆ÷²ÄÓÐÏÞ¹«Ë¾ÉÏº£¹ÚÁú·§ÃÅÓÐÏÞ¹«Ë¾
¹ãÎ÷ÄÏÄþÐÂÄÜ¿Æ¼¼¿ª·¢ÓÐÏÞ¹«Ë¾  ±±¾©º«´óÔªÉÌÃ³ÓÐÏÞ¹«Ë¾
ÎÞÎýÎ÷Ä·À³Ë¹Ê¯ÓÍ×¨ÓÃ¹ÜÖÆÔì¹«Ë¾ÉòÑôÊÐÈ«Í¨·§ÃÅ¹Ü¼þÖÆÔì¹«Ë¾
À¼ÖÝÊ¯ÓÍ»¯¹¤»úÆ÷×Ü³§  °Í¿ËÐîÄÜÆ÷£¨Ìì½ò£©ÓÐÏÞ¹«Ë¾
ÉÏº£¿Æ´´É«Æ×ÒÇÆ÷ÓÐÏÞ¹«Ë¾  Õã½ÀÖ¶¦²¨ÎÆ¹ÜÓÐÏÞ¹«Ë¾
ÉÏº£¹þµÏÍþ²»Ðâ¸ÖÓÐÏÞ¹«Ë¾  ÉÏº£ÊæÈðÆÕÊµÒµÓÐÏÞ¹«Ë¾
²¼µÂÂ³Ë¹ÈÈ¹¤¼¼ÊõÓÐÏÞ¹«Ë¾  ¸»Ë¹´ó¹øÂ¯
ÃÀ¹úÀïÆæ¹¤¾ß¹«Ë¾  À×µÏ£¨ÖÐ¹ú£©ÓÐÏÞ¹«Ë¾
Õã½Ì¨ÖÝ´óÑóÒºÑ¹ÕÍ¹ÜÉè±¸ÖÆÔì×Ü³§  ÉÏº£·îÌ©µç×ÓµçÆ÷Ôª¼þ³§ÓÐÏÞ¹«Ë¾
Ê¯ÓÍ´óÑ§¿ÂÁÖÈð¶û¿Æ¼¼ÓÐÏÞÔðÈÎ¹«Ë¾  Äþ²¨ÊÐÓî»ªµçÆ÷¹«Ë¾
Õã½ÓÀÒ»·§ÃÅ³§½ËÕ»ªÑô½ðÊô¹Ü¼þÓÐÏÞ¹«Ë¾
ÉÏº£Åµ²©»úÐµÉè±¸ÓÐÏÞ¹«Ë¾  Ìì½òÊÐÈðµÂÂÝ¸Ë±ÃÖÆÔì¼¼Êõ¹«Ë¾
½ÒõÊÐ½ÄÏ¸ßÑ¹¹Ü¼þ³§  ÉÏº£èªÍþ»úµçÉè±¸ÓÐÏÞ¹«Ë¾
Î÷°²¶«·½¸ÖÌú³§ÀÈ·»¿ª·¢Çø¹ÜµÀÈË»úÐµÉè±¸¹«Ë¾
ÎýÉ½ÊÐÐÂÒµ·À±¬µçÆøÓÐÏÞ¹«Ë¾Íþº£»¯¹¤Æ÷ÐµÓÐÏÞ¹«Ë¾ 
ÉÏº£Ò×Ì©»¯¹¤Éè±¸ÖÆÔìÓÐÏÞ¹«Ë¾  ÖÐÍâºÏ×Ê»ÍÊ¢¹ÜÒµÓÐÏÞ¹«Ë¾ÉÏº£°ì
ÉÏº£ÖÐÒâÊ¯ÓÍÉè±¸ÖÆÔìÓÐÏÞ¹«Ë¾  ÉÏº£°×º×»ªÐÂÀö»ªÌØÊâ¸ÖÖÆÆ·
½ÒõÊÐÆø»¯»úÐµ³§  À¼ÖÝÊ¯ÓÍ»úÐµÑÐ¾¿Ëù
ÉÏº£¾«Î¢·ÛÈÜ»úÐµÉè±¸ÓÐÏÞ¹«Ë¾  ÉÏº£´óÂ¡»úÆ÷³§

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

2001-11-15 Thread John Baldwin



On 16-Nov-01 Warner Losh wrote:
 I'm also seeing this in my X server...

Maxim has fixed the kernel, so it should work fine now.

 Warner

-- 

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-hackers in the body of the message

problems with 3Com 900TPO network card

2001-11-15 Thread Bri


Hi I have the 3com card that I listed above and I have a problem with the
network card light going off on the hub and the card it self basically
crashing for some reason which leaves the machine in an unstable state and
then prepares to reboot itself. this happens after 4 days of usage normally
all though if you down and up the interface every 2 days you can get 13 days
out of the machine.

When it crashes it gives a crash dump from the driver which I'll try and
take down next time it happens and maybe one of you guys will know why this
is happening to me.

thanks

Bri,


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

Re: sigreturn: eflags creash (fixed!)

2001-11-15 Thread Joe Clarke




On Thu, 15 Nov 2001, Maxim Sobolev wrote:

 Joe Clarke wrote:
 
  Sorry for the wide distribution, but I have sent email to both lists
  regarding this problem in the past.  It seems that while doing intensive
  threaded operations in Gnome applications, crashes occur with the
  following kernel message:
 
  sigreturn: eflags 0x280
 
  And, in .gnomerc-errors:
 
  Fatal error 'Thread has returned from sigreturn or longjump'
 
  The problem as I have found it is with libpng.  libpng uses MMX
  optimizations by default on FreeBSD.  If you apply the attached patch to
  patch-aa in /usr/ports/graphics/png, the problem goes away.  You only need
  to recompile and install libpng.  Reinstalling Gnome isn't necessary.  It
  seems the MMX optimizations are corrupting eflags, and when a thread tries
  to restore context after a signal, things go really wrong.
 
  The true fix will probably come in analyzing the MMX code in libpng.
  Unfortunately, I don't know enough about x86 assembly to be of much use
  here.  Hopefully this will help other experiencing the same problem.

 Very interesting, and weird if true. I'll test this tomorrow. In the
 meantime, could some CPU guru confirm or reject theoretical
 possibility of MMX user-level code causing problems to the kernel?

I learned about this by reading through some of the -hackers archives.
One person complained of similar errors trying to get xine to work on
FreeBSD.  Removing the MMX detection code fixed it.  I remembered libpng
also used MMX, so I removed the pnggccrd.c source, and voila!

Based on core dumps, strace output, and a lot of code surfing, this makes
sense to me.  Basically, any png-dependent app's thread that runs longer
than what ITIMER_PROF is set to gets hit with a SIGPROF.  When that
happens, things context switch.  eflags must have been corrupted by the
MMX code, thus sigreturn() bombs out, and causes uthread_kern to die as
well.  Here's what strace looks like when balsa tries to read a 33 MB
mailbox:

...
74202 --- SIGPROF (Profiling timer expired) ---
74202 --- SIGPROF (Profiling timer expired) ---
74202 gettimeofday({1005789324, 257513}, NULL) = 0
74202 sigprocmask(SIG_SETMASK, [], NULL) = 0
74202 sigaltstack({ss_sp=0x811b000, ss_flags=0, ss_size=40960}, NULL) = 0
74202 poll([{fd=5, events=POLLIN}, {fd=7, events=POLLIN}, {fd=10,
events=POLLIN}, {fd=11, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN},
{fd=12, events=POLLIN}], 6, 0) = 0
74202 sigreturn(0x81f2c64

When this happens, strace politely dies with a bus error.

Thanks for testing this, Maxim.  Hopefully someone can find the problem
and fix it for good.

Joe

P.S. my original patch sucks  I was in a hurry.  The one attached is
better.



 -Maxim




--- patch-aa.orig   Thu Nov 15 14:55:43 2001
+++ patch-aaThu Nov 15 14:55:57 2001
@@ -43,8 +43,8 @@
  
 -all: libpng.a pngtest
 +.if (${ARCH} == i386)
-+CFLAGS+=-DPNG_USE_PNGGCCRD
-+OBJS+=pnggccrd.o
++#CFLAGS+=-DPNG_USE_PNGGCCRD
++#OBJS+=pnggccrd.o
 +.endif
 +
 +.SUFFIXES: .c .so .o
@@ -91,5 +91,5 @@
  pngwtran.o: png.h pngconf.h
  pngwutil.o: png.h pngconf.h
  pngpread.o: png.h pngconf.h
-+pnggccrd.o: png.h pngconf.h pngasmrd.h
++#pnggccrd.o: png.h pngconf.h pngasmrd.h

M.D. , sise 572 chaussée

Re: FreeBSD on vmware

-STABLE NVidia drivers

RE: linux JVMs not handling SEGV well.

Re: FreeBSD on vmware

[hackers] Re: wake up on lan driver support

Re: FreeBSD on vmware

Re: kern.vm.kmem.size

_init execs in middle of code

RE: _init execs in middle of code

Re: _init execs in middle of code

has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)

Re: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)

Re: kernel malloc questions...

RE: has 'options LOCKF_DEBUG' ever worked? (w/ patch) (fwd)

Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflags creash (fixed!)]

RE: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflagscreash (fixed!)]

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflags creash (fixed!)]

Re: kernel malloc questions...

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: eflags creash (fixed!)]

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

ÖÐ¹úÊ¯ÓÍºÍÊ¯ÓÍ»¯¹¤Éè±¸¹¤ÒµÐ»á

Re: Using bit 21 of EFLAGS in user-mode [was: Re: sigreturn: efl

problems with 3Com 900TPO network card

Re: sigreturn: eflags creash (fixed!)

29 matches

Site Navigation

Mail list logo

Footer information