Re: linux emulation
From: Marcel Moolenaar [EMAIL PROTECTED]
Date: Tue, 31 Oct 2000 22:59:48 -0800
:: Anyone having problems with the linuxulator the past couple days?
::
::Define "past couple of days". I have a working linuxulator made on Oct
::29, 12:25 PST.
By following commit, makebdev() went away.
But there is sys/compat/linux/linux_stats.c:linux_ustat() that still
uses it.
---8--8--8--8--- Cut Here ---8--8--8--8---
phk 2000/10/31 02:58:17 PST
Modified files:
sys/i386/i386autoconf.c
sys/kern kern_conf.c
sys/sys conf.h
Log:
Deprecate devsw-d_bmaj entirely.
This removes support for booting current kernels with very old bootblocks.
Device driver writers: Please remove initializations for the d_bmaj
field in your cdevsw{}.
---8--8--8--8--- Cut Here ---8--8--8--8---
Hope this helps,
Haro
=--
_ _Munehiro (haro) Matsuda
-|- /_\ |_|_| Business Incubation Dept., Kubota Corp.
/|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome
Chuo-ku Tokyo 103-8310, Japan
Tel: +81-3-3245-3318 Fax: +81-3-3245-3315
Email: [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: /dev/random strangeness
On Tue, 31 Oct 2000 13:28:23 PST, Nathan Boeger wrote: I have looked through the list (I am new to this list) and saw some mention of the /dev/random. However I have a strange problem that was not mentioned. After I did a proper make world and updated my system to 5.0-CURRENT, my /dev/random services do not "start ?". You probably haven't used mergemaster(8) to update your /etc/rc script. If you don't know what mergemaster(8) is, you really need to catch up on your documentation reading. A shortcut might be to read src/UPDATING. :-) While you should really have divined this answer from the archives, it's understandable that you may not have read through every single one of the ridiculous messages that have surrounded the recent import of the new random device. When people argue fists first, it makes for a lot of noise. :-( Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
dev/usb/if_aue.c multicast patch
In Japanese mailing-list, Ryoji Kato-san [EMAIL PROTECTED] reported patch for if_aue.c to receive multicast packet correctly. # http://www.clave.gr.jp/ml/bsd-nomads/29/msg00084.html (Japanese) One of problem may be caused by too large mask (1 (h 0xF)) for 8 bit register. I'm using this patch and it works fine in IPv6 environment. Bill, please review attached patch or original one in above URL. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project if_aue.c.diff
HP ScanJet 5200C seems to be supported!
Daniel reported that the HP ScanJet 5200C USB scanner works with the uscanner driver. This means that most probably the following scanners now will work: HP ScanJet 4100C HP ScanJet 5200C HP ScanJet 6300C Note: This excludes the 4200C as it _is_ not compatible with the rest of them. Thanks to Daniel for pointing out a silly CutPaste error on my side. Please mail me any additional names of devices that work so I can add them to HARDWARE.TXT. Nick -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ -- Forwarded message -- Date: Wed, 01 Nov 2000 11:20:21 +1030 (CST) From: Daniel O'Connor [EMAIL PROTECTED] To: Nick Hibma [EMAIL PROTECTED] Cc: USB BSD list [EMAIL PROTECTED] Subject: Re: HP ScanJet 5200C On 01-Nov-00 Nick Hibma wrote: [sound of someone slapping forehead] Do'h! Cutpaste error when copying stuff from ugen. Here is the patch. Both committed to stable and current. Please let me know whether this makes your scanner work. It's much more talkative now.. :) :) OK, a preview scan worked great. *bounce* --- 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: Driver Floppy implementation (Re: make release breakage -dokern.sh patch 2)
I'm not sure whether the problem of loading secondary usb modules is a problem in 4.x but it is easy to try. Boot a machine without usb support compiled in. after login, kldload usb, then the miibus and then the if_aue modules. If that works, you should be ok. I cannot test this as at the moment as I don't have a STABLE box (will have once the first RC comes out of JKH factories). Nick On Mon, 30 Oct 2000, Takanori Watanabe wrote: In message [EMAIL PROTECTED], Tatsumi Hosokawa $B$5$s$$$o$/(B: I moved PCI/PCCARD/USB if_xx.ko driver to mfsroot.flp, and I've got 100KB of free blocks in the first floppy. If we move more drivers to mfsroot.flp or coming drivers.flp, we can get not only free blocks in the first floppy, but also more installation devices. Just FYI: If usb itself is module-ifed, USB ether modules cannot be load until MODULE_DEPEND,MODULE_VERSION is defined. Takanori Watanabe a href="http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html" Public Key/a Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
rl driver problem in -current
Hi! There is a problem in rl's driver in recent -current kernel. ... rl0: Realtek rl0: couldn't map memory kernel trap 12 with interrupts disabled -current kernel from 20 Oct 2000 works fine. I know I should provide more info about trap, but I can't cut'n'paste boot messages. What information _exactly_ needed to fix it? Dmitry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: making an install CD
I tried this, but the make fails with error install:/usr/obj/usr/src/include/osreldate.h: No such file or directory I just got the brand new current source, rebuilt the world and updated the kernel. If the source file is supposed to be there, its probably missing on the server. Any toughts - am I doing something wrong? Jan On Wed, 1 Nov 2000, Daniel O'Connor wrote: On 01-Nov-00 [EMAIL PROTECTED] wrote: Does anybody have a link to instructions for making an install CD with the 'current' state. Well, you need to have the CVS repo handy for starters, then try cd /usr/src/release make release CHROOTDIR=/some/place/with/space CVSROOT=/my/cvsroot Read the Makefile for handy tips :) --- 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
ABI is broken??
Hi, I'm not sure what exactly caused this behaviour (I can guess two potential victims: O'Brien's changes in crt stuff and recent Polstra's changes in libgcc_r), but it seems that some programs built on the previous -current from 27 October immediately segfault when I'm trying to run then on system installed from today's sources. The segfault disappeared when I recompiled affected program. With this message I'm attaching short backtrace. -Maxim root@notebook# galeon GNU gdb 4.18 This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... (gdb) r Starting program: /usr/X11R6/bin/galeon-bin (no debugging symbols found)... [...] (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #1 0x806e782 in __register_frame_info () #2 0x287a3137 in _init () from /usr/lib/libc_r.so.4 #3 0x2879ffe5 in _init () from /usr/lib/libc_r.so.4 #4 0x280797fd in _rtld () from /usr/libexec/ld-elf.so.1 (gdb) q To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Using tape drives in linux emulation
It seems that linux progs are using foreign ioctls on tape drives which of course will fail. Is there anyone already working on an emulation for these? Are there similar problems for seriel devices? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NTFS driver broken
Hi, I wonder if anyone noticed, but as of today's current NTFS driver is broken. I can mount a volume, list files on it, but when I'm trying to read any file I have famous "Inappropriate ioctl...". Can someone look what is wrong with it? -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
On Wed, Nov 01, 2000 at 19:17:26 +0200, Maxim Sobolev wrote: Hi, I'm not sure what exactly caused this behaviour (I can guess two potential victims: O'Brien's changes in crt stuff and recent Polstra's changes in libgcc_r), but it seems that some programs built on the previous -current from 27 October immediately segfault when I'm trying to run then on system installed from today's sources. The segfault disappeared when I recompiled affected program. With this message I'm attaching short backtrace. -Maxim #0 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 Same for me in -stable (4.2-BETA) and python-1.6. After rebuilding the port this disappeared. My gdb showed the same error message as the quoted above. Regards. -- Udo Schweigert, Siemens AG | Voice : +49 89 636 42170 ZT IK 3, Siemens CERT| Fax: +49 89 636 41166 D-81730 Muenchen / Germany | email : [EMAIL PROTECTED] PGP-2/5 fingerprint | D8 A5 DF 34 EC 87 E8 C6 E2 26 C4 D0 EE 80 36 B2 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Driver Floppy implementation (Re: make release breakage - dokern.sh patch 2)
I'm not sure whether the problem of loading secondary usb modules is a problem in 4.x but it is easy to try. Boot a machine without usb support compiled in. after login, kldload usb, then the miibus and then the if_aue modules. If that works, you should be ok. I cannot test this as at the moment as I don't have a STABLE box (will have once the first RC comes out of JKH factories). I usually do the following: # kldload usb (probes USB controllers) # kldload miibus # kldload if_aue # usbd -f /dev/usb0 If the device has already been plugged in, starting usbd will cause it to be probed/attached by the aue driver. If not, it will be detected when it's plugged in later. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Marcel Moolenaar writes:
Wesley Morgan wrote:
Anyone having problems with the linuxulator the past couple days?
Define "past couple of days". I have a working linuxulator made on Oct
29, 12:25 PST.
phk took away mkbdev on 10/31. The following "fixes" it, but I
have no idea if it is correct:
Drew
Index: compat/linux/linux_stats.c
===
RCS file: /home/ncvs/src/sys/compat/linux/linux_stats.c,v
retrieving revision 1.22
diff -u -r1.22 linux_stats.c
--- compat/linux/linux_stats.c 2000/08/22 01:51:11 1.22
+++ compat/linux/linux_stats.c 2000/11/01 18:34:05
@@ -360,8 +379,8 @@
* dev_t returned from previous syscalls. Just return a bzeroed
* ustat in that case.
*/
- dev = makebdev(uap-dev 8, uap-dev 0xFF);
- if (vfinddev(dev, VBLK, vp)) {
+ dev = makedev(uap-dev 8, uap-dev 0xFF);
+ if (vfinddev(dev, VCHR, vp)) {
if (vp-v_mount == NULL)
return (EINVAL);
stat = (vp-v_mount-mnt_stat);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
I was just looking at that piece of code, and I couldn't entirely
make out what it was even trying to do. Can somebody more
linuxolator savy explain what the function linux_ustat() should
produce.
I also find this comment rather interesting...
/*
* XXX - Don't return an error if we can't find a vnode for the
* device. Our dev_t is 32-bits whereas Linux only has a 16-bits
* dev_t. The dev_t that is used now may as well be a truncated
* dev_t returned from previous syscalls. Just return a bzeroed
* ustat in that case.
*/
Poul-Henning
In message [EMAIL PROTECTED], Andrew Gallatin
writes:
Marcel Moolenaar writes:
Wesley Morgan wrote:
Anyone having problems with the linuxulator the past couple days?
Define "past couple of days". I have a working linuxulator made on Oct
29, 12:25 PST.
phk took away mkbdev on 10/31. The following "fixes" it, but I
have no idea if it is correct:
Drew
Index: compat/linux/linux_stats.c
===
RCS file: /home/ncvs/src/sys/compat/linux/linux_stats.c,v
retrieving revision 1.22
diff -u -r1.22 linux_stats.c
--- compat/linux/linux_stats.c 2000/08/22 01:51:11 1.22
+++ compat/linux/linux_stats.c 2000/11/01 18:34:05
@@ -360,8 +379,8 @@
* dev_t returned from previous syscalls. Just return a bzeroed
* ustat in that case.
*/
- dev = makebdev(uap-dev 8, uap-dev 0xFF);
- if (vfinddev(dev, VBLK, vp)) {
+ dev = makedev(uap-dev 8, uap-dev 0xFF);
+ if (vfinddev(dev, VCHR, vp)) {
if (vp-v_mount == NULL)
return (EINVAL);
stat = (vp-v_mount-mnt_stat);
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
On Wed, 1 Nov 2000, John Polstra wrote: In article [EMAIL PROTECTED], Maxim Sobolev [EMAIL PROTECTED] wrote: I'm not sure what exactly caused this behaviour (I can guess two potential victims: O'Brien's changes in crt stuff and recent Polstra's changes in libgcc_r), but it seems that some programs built on the previous -current from 27 October immediately segfault when I'm trying to run then on system installed from today's sources. The segfault disappeared when I recompiled affected program. With this message I'm attaching short backtrace. [...] Program received signal SIGSEGV, Segmentation fault. 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #1 0x806e782 in __register_frame_info () #2 0x287a3137 in _init () from /usr/lib/libc_r.so.4 #3 0x2879ffe5 in _init () from /usr/lib/libc_r.so.4 #4 0x280797fd in _rtld () from /usr/libexec/ld-elf.so.1 Here are all the random facts which, when put together, explain what is going on. Your old application was (like all -pthread programs) linked with "/usr/lib/libgcc_r.a". That library contains a function "__register_frame_info" which uses some of the facilities of the pthreads library "libc_r". The pthreads library has to be initialized before it can be used, by a call to _thread_init. If some functions such as pthread_mutex_lock are called before the library has been initialized, a segmentation violation results. _thread_init is called automatically from libc_r's _init function when the dynamic linker loads the library. Unfortunately, that isn't early enough. libgcc_r is the first thing to be initialized, and it calls pthread_mutex_lock before _thread_init has been called. Or rather I should say that OLD versions of libgcc_r did that -- because they were buggy. In other words, your old application was linked with a buggy version of libgcc_r, but it didn't become apparent until now. It didn't become apparent until now because our crtbegin.o and crtend.o were also buggy. They failed to call __register_frame_info. This was a problem for C++ programs using exceptions, especially when the gcc port was used and DWARF2 exception handling was selected. Now we have fixed crtbegin.o and crtend.o, and we have fixed libgcc_r.a. But it causes problems for your old application because the new crtbegin.o and crtend.o (linked into the new shared libraries such as libc_r) call __register_frame_info in your old, buggy, statically linked libgcc_r.a. Are you dizzy yet? Yes ;-) To sum up, your old executable contains the bug but it wasn't triggered until the recent changes. Now, what can or should we do about this? Arguably we should simply say in the release notes, "Relink your old multithreaded applications. They had a bug which is now fixed." But if there are binary-only commercial apps which exhibit the problem, this solution is useless. I don't know whether there are any such apps, but I doubt it. N.B., Linux apps don't count because they were never linked with our libgcc_r in the first place. Or we can try to work around it, but there aren't any perfectly nice ways to do so. Here are some possibilities: - Put a hack in the threads library so that whenever pthread_mutex_lock is called it checks to make sure that the threads library has been initialized, and if not, it calls _thread_init. This is a poor solution because it adds overhead to a rather performance-critical function -- though admittedly the overhead is very small. Another potential problem is that there could be a race condition if several threads all called pthread_mutex_lock at once before the threads library had been initialized. I don't think the race condition would materialize, though, since the first call would come from libgcc_r, well before the application had gotten control. - Put a hack into the dynamic linker to call _thread_init very early if that symbol was defined. I like this solution even less, because it's too hackish. The dynamic linker isn't the place for special hooks like that. - Put a hack into crtbegin.o or crtend.o. But we are using the standard GNU versions of these, and I really really don't want to change that. In any case, it's the wrong place for the work-around. Overall I would lean toward putting the hack into pthread_mutex_lock. Comments? If that's the lesser evil, then I guess it's OK with me. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: Overall I would lean toward putting the hack into pthread_mutex_lock. Comments? If that's the lesser evil, then I guess it's OK with me. Thanks for replying so quickly. I'll test this to make sure it really works, and then commit it. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
John Polstra wrote: In article [EMAIL PROTECTED], Maxim Sobolev [EMAIL PROTECTED] wrote: I'm not sure what exactly caused this behaviour (I can guess two potential victims: O'Brien's changes in crt stuff and recent Polstra's changes in libgcc_r), but it seems that some programs built on the previous -current from 27 October immediately segfault when I'm trying to run then on system installed from today's sources. The segfault disappeared when I recompiled affected program. With this message I'm attaching short backtrace. [...] Program received signal SIGSEGV, Segmentation fault. 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #1 0x806e782 in __register_frame_info () #2 0x287a3137 in _init () from /usr/lib/libc_r.so.4 #3 0x2879ffe5 in _init () from /usr/lib/libc_r.so.4 #4 0x280797fd in _rtld () from /usr/libexec/ld-elf.so.1 Here are all the random facts which, when put together, explain what is going on. Your old application was (like all -pthread programs) linked with "/usr/lib/libgcc_r.a". That library contains a function "__register_frame_info" which uses some of the facilities of the pthreads library "libc_r". The pthreads library has to be initialized before it can be used, by a call to _thread_init. If some functions such as pthread_mutex_lock are called before the library has been initialized, a segmentation violation results. _thread_init is called automatically from libc_r's _init function when the dynamic linker loads the library. Unfortunately, that isn't early enough. libgcc_r is the first thing to be initialized, and it calls pthread_mutex_lock before _thread_init has been called. Or rather I should say that OLD versions of libgcc_r did that -- because they were buggy. In other words, your old application was linked with a buggy version of libgcc_r, but it didn't become apparent until now. It didn't become apparent until now because our crtbegin.o and crtend.o were also buggy. They failed to call __register_frame_info. This was a problem for C++ programs using exceptions, especially when the gcc port was used and DWARF2 exception handling was selected. Now we have fixed crtbegin.o and crtend.o, and we have fixed libgcc_r.a. But it causes problems for your old application because the new crtbegin.o and crtend.o (linked into the new shared libraries such as libc_r) call __register_frame_info in your old, buggy, statically linked libgcc_r.a. Are you dizzy yet? To sum up, your old executable contains the bug but it wasn't triggered until the recent changes. Now, what can or should we do about this? Arguably we should simply say in the release notes, "Relink your old multithreaded applications. They had a bug which is now fixed." But if there are binary-only commercial apps which exhibit the problem, this solution is useless. I don't know whether there are any such apps, but I doubt it. N.B., Linux apps don't count because they were never linked with our libgcc_r in the first place. Or we can try to work around it, but there aren't any perfectly nice ways to do so. Here are some possibilities: - Put a hack in the threads library so that whenever pthread_mutex_lock is called it checks to make sure that the threads library has been initialized, and if not, it calls _thread_init. This is a poor solution because it adds overhead to a rather performance-critical function -- though admittedly the overhead is very small. Another potential problem is that there could be a race condition if several threads all called pthread_mutex_lock at once before the threads library had been initialized. I don't think the race condition would materialize, though, since the first call would come from libgcc_r, well before the application had gotten control. - Put a hack into the dynamic linker to call _thread_init very early if that symbol was defined. I like this solution even less, because it's too hackish. The dynamic linker isn't the place for special hooks like that. - Put a hack into crtbegin.o or crtend.o. But we are using the standard GNU versions of these, and I really really don't want to change that. In any case, it's the wrong place for the work-around. Overall I would lean toward putting the hack into pthread_mutex_lock. Comments? Huh, why we can't just bump libc_r version number and put older (buggy) version into lib/compat as usually? This would not require any ugly hacks at all. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
In article [EMAIL PROTECTED], Maxim Sobolev [EMAIL PROTECTED] wrote: John Polstra wrote: Overall I would lean toward putting the hack into pthread_mutex_lock. Comments? Huh, why we can't just bump libc_r version number and put older (buggy) version into lib/compat as usually? This would not require any ugly hacks at all. The bug wasn't in libc_r -- it was in libgcc_r. That's a static library, so it doesn't have a version number. And it is statically linked into old executables. Nothing we do to libgcc_r will help old executables, because they won't even use the new libgcc_r. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: making an install CD
On Wed, Nov 01, 2000 at 09:53:59AM -0700, [EMAIL PROTECTED] wrote: I tried this, but the make fails with error install:/usr/obj/usr/src/include/osreldate.h: No such file or directory ^ !! I just got the brand new current source, rebuilt the world and updated the kernel. If the source file is supposed to be there, its probably missing on the server. Any toughts - am I doing something wrong? You need at least to do a make buildworld first See the path above ... -- Andreas Klemm Powered by FreeBSD SMP Songs from our band 64Bitshttp://www.apsfilter.org/64bits.html My homepage http://people.FreeBSD.ORG/~andreas Please note: Apsfilter got a NEW HOMEhttp://www.apsfilter.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Poul-Henning Kamp wrote: I was just looking at that piece of code, and I couldn't entirely make out what it was even trying to do. Can somebody more linuxolator savy explain what the function linux_ustat() should produce. The following comment explains what linux_ustat should do: /* * lu.f_fname and lu.f_fpack are not used. They are always zeroed. * lu.f_tinode and lu.f_tfree are set from the device's super block. */ linux_ustat fills in a structure with the above mention fields. The meaning of f_tinode and f_tfree are explained by the following two statements: lu.f_tfree = stat-f_bfree; lu.f_tinode = stat-f_ffree; In short: given the (u)dev_t, get the FS statistics and return the number of free blocks and inodes of the FS on that device. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
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
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: NTFS driver broken
I wonder if anyone noticed, but as of today's current NTFS driver is broken. I can mount a volume, list files on it, but when I'm trying to read any file I have famous "Inappropriate ioctl...". Can someone look what is wrong with it? It's been broken for me for about a week (could have been longer). I mentioned it on this list, but wanted to wait for someone to jump up and say "Oh, it's just this this probably" before digging into it. If there's still noone like that, I guess I'll have to make my promise true and dive into the code.I'll get back on this. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Poul-Henning Kamp wrote: In short: given the (u)dev_t, get the FS statistics and return the number of free blocks and inodes of the FS on that device. But the udev_t is a (32bit truncated to) 16bit one, right ? Correct. In that case it will usually not work: crw-r- 1 root operator 116, 0x00010002 1 Jan 1970 /dev/ad0 crw-r- 1 root operator 116, 0x0002 1 Jan 1970 /dev/ad0s1a [snip] It won't always work. Considering the fact that we were likely to return statistics for the wrong filesystem with the old code, and most likely cannot return the right statistics anyway, I think we should just return zero for those values (or some other more sensible values) I think we should try to return the right statistics in the case where we have it wrong now instead of returning the wrong statistics in the case where we have it right now. When we have it wrong, we're likely to return zero anyway. The only case that pops up in my mind that may cause us to return the statistics of a different device than the one intended is when the minor number is a sequence and we've truncated sequence S, with S 255 into S % 255. This is not very likely. Hmmm... the strange assignment of NFS mounts might be a problem as well (warning: vague recollections in combination with memory leaks of dated info and mental cross-talk may make this statement slightly off :-) -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
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: ABI is broken??
On Wed, 01 Nov 2000 21:09:12 +0200, Maxim Sobolev [EMAIL PROTECTED] said: Huh, why we can't just bump libc_r version number and put older (buggy) version into lib/compat as usually? This would not require any ugly hacks at all. If you want to bump libc_r's version, we should do it to libc as well, and in that case there are a large number of ABI fixes that I have queued up which should be done at the same time. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
Poul-Henning Kamp wrote: So, where do the programs that call this syscall have the udev_t from ? Most likely from stat, lstat and fstat. Do they know it to be a mountpoint ? That is implied by the way they get the dev_t. Do the know it to be a bmajor or cmajor style udev_t ? AFAICT, filesystems are always on block-devices in Linux. Being Linux they only know one kind, right ? Linux has the distinction between block and character devices. I don't see any evidence that block devices can be accessed as character devices as well (ie: there's /dev/fd0, but no /dev/rfd0). In that case, makebdev() has been wrong ever since we changed to mount cdevs in FreeBSD. In the sense that we would never find the vnode and thus always return zero stats, right? You should simply change the makebdev() to makedev() and VBLK to VCHR in the vfinddev() right after. Right-o :-) It's still mightily bogus though... Yes. A more dynamic solution needs to be used that creates mappings (and dev_t values) on the fly. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: linux emulation
In message [EMAIL PROTECTED], Marcel Moolenaar writes: 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
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
if_rl.c broken ? Realtek 8139 not longer recognised.
Hi, I have a realtek ethernet card. The normal dmesg is this: rl0: RealTek 8139 10/100BaseTX port 0xb400-0xb4ff mem 0xd900-0xd9ff irq 10 at device 11.0 on pci0 rl0: Ethernet address: 00:e0:7d:7d:cd:35 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto With the change to 8bit wide eeprom reads instead of the 6bit wide reads, the message is now: rl0: RealTek 8139 10/100BaseTX port 0xb400-0xb4ff mem 0xd900-0xd9ff irq 10 at device 11.0 on pci0 rl0: Ethernet address: 00:e0:7d:7d:cd:35 rl0: unknown device ID: 4a7 I changed if_rl.c to confirm that it really is the 6/8 bit change: === trinity(17)/usr/src/sys/pci # cvs diff if_rl.c Index: if_rl.c === RCS file: /export5/full.src/src/sys/pci/if_rl.c,v retrieving revision 1.49 diff -c -r1.49 if_rl.c *** if_rl.c 2000/10/30 07:54:38 1.49 --- if_rl.c 2000/11/01 19:39:02 *** *** 896,903 --- 896,905 rl_reset(sc); sc-rl_eecmd_read = RL_EECMD_READ_6BIT; rl_read_eeprom(sc, (caddr_t)rl_did, 0, 1, 0); + #ifdef notyet if (rl_did != 8129) sc-rl_eecmd_read = RL_EECMD_READ_8BIT; + #endif This is not meant as a patch, just a trick for me to confirm it was the 6/8 bit change. The change occured from 1.48 to 1.49 of if_rl.c Regards, Frank -- ~/.signature not found: wellknown error 42 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: making an install CD
I understand. The strange thing is that I have to do make clean after make world, because if I dont, the build of the new kernel fails. Of course, after the make clean the obj files are missing jan I tried this, but the make fails with error install:/usr/obj/usr/src/include/osreldate.h: No such file or directory ^ !! I just got the brand new current source, rebuilt the world and updated the kernel. If the source file is supposed to be there, its probably missing on the server. Any toughts - am I doing something wrong? You need at least to do a make buildworld first See the path above ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
On Wed, Nov 01, 2000 at 03:19:36PM -0500, Garrett Wollman wrote: If you want to bump libc_r's version, we should do it to libc as well, and in that case there are a large number of ABI fixes that I have queued up which should be done at the same time. Any reason to not get them in -current now and make the bump? -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
subscribe
how can I subscribe
HP Deskjet 840C supported?
I've just gotten a HP Deskjet 840C (Bundled with a HP C200 camera) Is it just a windows-printer, and/or is it supported under Fbsd? Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HP Deskjet 840C supported?
[A best this belonged on -questions though it's not really a FreeBSD question at all.] On Thu, Nov 02, 2000 at 12:22:45AM +0100, Leif Neland wrote: I've just gotten a HP Deskjet 840C (Bundled with a HP C200 camera) Is it just a windows-printer, and/or is it supported under Fbsd? Under FreeBSD (and unix in general) if a printer isn't PostScript, the question is, does GhostScript support it. If so, it's supported, if not it isn't. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: if_rl.c broken ? Realtek 8139 not longer recognised.
Hi, I have a realtek ethernet card. The normal dmesg is this: rl0: RealTek 8139 10/100BaseTX port 0xb400-0xb4ff mem 0xd900-0xd9ff irq 10 at device 11.0 on pci0 rl0: Ethernet address: 00:e0:7d:7d:cd:35 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto With the change to 8bit wide eeprom reads instead of the 6bit wide reads, the message is now: rl0: RealTek 8139 10/100BaseTX port 0xb400-0xb4ff mem 0xd900-0xd9ff irq 10 at device 11.0 on pci0 rl0: Ethernet address: 00:e0:7d:7d:cd:35 rl0: unknown device ID: 4a7 I changed if_rl.c to confirm that it really is the 6/8 bit change: Just fixed this. It should be 0x8129 that we compare with, not 8129. Sorry about that. Note that the cardbus hacks aren't in -stable yet so it wasn't affected. -Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
WARNING: driver bpf should register devices with make_dev() (dev_t =#bpf/0)
Subject says it all. I get: WARNING: driver bpf should register devices with make_dev() (dev_t = "#bpf/0") probably at first usage. Card is an xe PC Card. I know I will probably get flamed for not RTF*, but I couldn't find a clue anywhere... Bye, Andrea -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Driver Floppy implementation (Re: make release breakage - dokern.sh patch 2)
My driver-floppy patch broke "make release" on current.jp.freebsd.org (ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i3865.0-CURRENT-20001101-JPSNAP.log). Of course "make boot.flp" works very well on my enviroment. I'm debugging this problem, but it'll take hours and hours because testing "make release" takes about 8 hours on my machine. Anyway, I'll fix this bug as soon as possible. -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
On Wed, 1 Nov 2000 14:43:55 -0800, "David O'Brien" [EMAIL PROTECTED] said: Any reason to not get [libc ABI changes] in -current now and make the bump? Mostly because they're too small to be worth the pain. I'm waiting for something more significant that I can piggy-back on. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
current paging strategy
What paging strategy does FreeBSD currently use? Is it LRU or some approximation to it? How much memory does this strategy take up in its current implementation? Thank you for any information or links, Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: * watchdog timeout (Was: dc0: watchdog timeout)
In message [EMAIL PROTECTED] [EMAIL PROTECTED] writes: : Probably not related at all, but on -current I am seeing: : xe0: watchdog timeout; resetting card : It happens just once, at boot time or after I insert the PC Card (Compaq : whatever). After that, everything works ok. Generally watchdog timeouts from pccard devices mean that your irqs are fubar'd. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Driver Floppy implementation (Re: make release breakage - dokern.sh patch 2)
At Thu, 02 Nov 2000 10:34:03 +0900, Tatsumi Hosokawa [EMAIL PROTECTED] wrote: My driver-floppy patch broke "make release" on current.jp.freebsd.org (ftp://current.jp.FreeBSD.org/pub/FreeBSD/snapshots/i3865.0-CURRENT-20001101-JPSNAP.log). Of course "make boot.flp" works very well on my enviroment. I'm debugging this problem, but it'll take hours and hours because testing "make release" takes about 8 hours on my machine. Anyway, I'll fix this bug as soon as possible. Hmm. Binaries on current.freebsd.org seems to be successfuly compiled. I'm not guilty :-). % gzip kern-20001028.flp kern-20001101.flp (got from current.freebsd.org) % ls -l kern-20001* -rw-r--r-- 1 hosokawa hosokawa 1330551 11/ 2 13:53 kern-20001028.flp.gz -rw-r--r-- 1 hosokawa hosokawa 1245853 11/ 2 13:50 kern-20001101.flp.gz Maybe it's current.jp.freebsd.org's problem and I'll talk with the administrator of this host. -- Tatsumi Hosokawa [EMAIL PROTECTED] http://www.sm.rim.or.jp/~hosokawa/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
hi, there! On Wed, 1 Nov 2000, John Polstra wrote: Here are all the random facts which, when put together, explain what is going on. Your old application was (like all -pthread programs) linked with "/usr/lib/libgcc_r.a". That library contains a function "__register_frame_info" which uses some of the facilities of the pthreads library "libc_r". The pthreads library has to be initialized before it can be used, by a call to _thread_init. If some functions such as pthread_mutex_lock are called before the library has been initialized, a segmentation violation results. [...] Overall I would lean toward putting the hack into pthread_mutex_lock. Comments? do we still need uthread_autoinit.cc? /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: WARNING: driver bpf should register devices with make_dev() (dev_t =#bpf/0)
[EMAIL PROTECTED] wrote: WARNING: driver bpf should register devices with make_dev() (dev_t = "#bpf/0") probably at first usage. Card is an xe PC Card. I know I will probably get flamed for not RTF*, but I couldn't find a clue anywhere... I get it as well. IIRC, it simply means that the bpf pseudo device needs to be updated, but is otherwise harmless. I forgot the details, but it's all in the mailinglist archives. Somewhere... :-) -- 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: current paging strategy
What paging strategy does FreeBSD currently use? Is it LRU or some approximation to it? How much memory does this strategy take up in its current implementation? It's probably nothing like anything you've heard of before. It's closest to LOU (least often used). We look at the page's reference flag and increment/decrement a counter depending on it. The rate that we look at the reference flag is also roughly proportional to the rate at which new pages are needed. This algorithm has proven to be extremely effective and does much better than simple LRU. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - 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: current paging strategy
Interesting. THis needs about two bytes per page for the counter? JAn On Wed, 1 Nov 2000, David Greenman wrote: What paging strategy does FreeBSD currently use? Is it LRU or some approximation to it? How much memory does this strategy take up in its current implementation? It's probably nothing like anything you've heard of before. It's closest to LOU (least often used). We look at the page's reference flag and increment/decrement a counter depending on it. The rate that we look at the reference flag is also roughly proportional to the rate at which new pages are needed. This algorithm has proven to be extremely effective and does much better than simple LRU. -DG David Greenman Co-founder, The FreeBSD Project - http://www.freebsd.org President, TeraSolutions, Inc. - 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
US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.COM)=
VERY JOKE..! SEE PRESIDENT AND FBI TOP SECRET PICTURES.. DOMEO.JPG.vbs
Re: Using tape drives in linux emulation
[cc'd to [EMAIL PROTECTED]; please remove -current on future replies] Bernd Walter wrote: It seems that linux progs are using foreign ioctls on tape drives which of course will fail. Of course? Is there anyone already working on an emulation for these? AFIACT, no. Are there similar problems for seriel devices? Probably. It's quite likely we don't support less frequently used or very specialized ioctls. These are mostly implemented on a need-to-have basis triggered by a can-be-done condition (what?) Do you know what you need? -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Virus Notification: A virus has been detected in a message in which you where a recipient
From: Peter Wagner [SMTP:[EMAIL PROTECTED]] To: Date: Thu, Nov 02 2000, 3:34:51 AM Subject:US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.CO M)= The message contained 1 virus(es): domeo.jpg.vbs infected with the VBS/LoveLetter_based@mm virus - - - Virus Notification: A virus has been detected in a message in which you where a recipient! Check the original message. If the attachment could not be repaired it was Deleted from the message. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Report to Recipient(s)
Incident Information:- Originator:[EMAIL PROTECTED] Recipients:FreeBSD List [EMAIL PROTECTED] Subject: US PRESIDENT AND FBI SECRETS =PLEASE VISIT = (http://WWW.2600.CO M)= WARNING: The file DOMEO.JPG.vbs you received was infected with the VBS/LoveLetter@MM virus. The file attachment was not successfully cleaned. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ABI is broken??
In article [EMAIL PROTECTED], Maxim Sobolev [EMAIL PROTECTED] wrote: I'm not sure what exactly caused this behaviour (I can guess two potential victims: O'Brien's changes in crt stuff and recent Polstra's changes in libgcc_r), but it seems that some programs built on the previous -current from 27 October immediately segfault when I'm trying to run then on system installed from today's sources. The segfault disappeared when I recompiled affected program. With this message I'm attaching short backtrace. [...] Program received signal SIGSEGV, Segmentation fault. 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 (gdb) bt #0 0x287de417 in pthread_mutex_lock () from /usr/lib/libc_r.so.4 #1 0x806e782 in __register_frame_info () #2 0x287a3137 in _init () from /usr/lib/libc_r.so.4 #3 0x2879ffe5 in _init () from /usr/lib/libc_r.so.4 #4 0x280797fd in _rtld () from /usr/libexec/ld-elf.so.1 Here are all the random facts which, when put together, explain what is going on. Your old application was (like all -pthread programs) linked with "/usr/lib/libgcc_r.a". That library contains a function "__register_frame_info" which uses some of the facilities of the pthreads library "libc_r". The pthreads library has to be initialized before it can be used, by a call to _thread_init. If some functions such as pthread_mutex_lock are called before the library has been initialized, a segmentation violation results. _thread_init is called automatically from libc_r's _init function when the dynamic linker loads the library. Unfortunately, that isn't early enough. libgcc_r is the first thing to be initialized, and it calls pthread_mutex_lock before _thread_init has been called. Or rather I should say that OLD versions of libgcc_r did that -- because they were buggy. In other words, your old application was linked with a buggy version of libgcc_r, but it didn't become apparent until now. It didn't become apparent until now because our crtbegin.o and crtend.o were also buggy. They failed to call __register_frame_info. This was a problem for C++ programs using exceptions, especially when the gcc port was used and DWARF2 exception handling was selected. Now we have fixed crtbegin.o and crtend.o, and we have fixed libgcc_r.a. But it causes problems for your old application because the new crtbegin.o and crtend.o (linked into the new shared libraries such as libc_r) call __register_frame_info in your old, buggy, statically linked libgcc_r.a. Are you dizzy yet? To sum up, your old executable contains the bug but it wasn't triggered until the recent changes. Now, what can or should we do about this? Arguably we should simply say in the release notes, "Relink your old multithreaded applications. They had a bug which is now fixed." But if there are binary-only commercial apps which exhibit the problem, this solution is useless. I don't know whether there are any such apps, but I doubt it. N.B., Linux apps don't count because they were never linked with our libgcc_r in the first place. Or we can try to work around it, but there aren't any perfectly nice ways to do so. Here are some possibilities: - Put a hack in the threads library so that whenever pthread_mutex_lock is called it checks to make sure that the threads library has been initialized, and if not, it calls _thread_init. This is a poor solution because it adds overhead to a rather performance-critical function -- though admittedly the overhead is very small. Another potential problem is that there could be a race condition if several threads all called pthread_mutex_lock at once before the threads library had been initialized. I don't think the race condition would materialize, though, since the first call would come from libgcc_r, well before the application had gotten control. - Put a hack into the dynamic linker to call _thread_init very early if that symbol was defined. I like this solution even less, because it's too hackish. The dynamic linker isn't the place for special hooks like that. - Put a hack into crtbegin.o or crtend.o. But we are using the standard GNU versions of these, and I really really don't want to change that. In any case, it's the wrong place for the work-around. Overall I would lean toward putting the hack into pthread_mutex_lock. Comments? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
