Re: Any chance of release patch being committed?
On Fri, 04 May 2001 00:00:58 +0200, J Wunsch wrote: We are, but why would we use anything else than GENERIC for it, seriously? I'd never roll a `release' for my current machine. When you get commitment to a fixed hardware configuration for two years and you want to leave your datacenter full of hosts ready to power up and play off a custom CDROM, a release that uses a custom kernel is desirable. That said, I don't think that the release should pick up KERNCONF. I think a middle-ground option is to have the release pick up RELEASE_KERNCONF. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
You've Been Added!
This message is to confirm the addition of your email address: [EMAIL PROTECTED] to the BlackOffers.com Newsletters Subscribe Me mailing list. If you feel you have received this notice in error, please visit the BlackOffers.com Newsletters Subscribe Me mailing list at our website: http://www.mybmail.com to remove yourself automatically, or click the link below: http://mybmail.com/cgi-bin/info/s.pl?r=1l=16e=current=:freebsd.org Thank you, BlackOffers.com Newsletters To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
You've Been Removed!
This message is to confirm the removal of your email address: [EMAIL PROTECTED] from the BlackOffers.com Newsletters Subscribe Me mailing list. We're sorry to see you go! If you feel you have received this notice in error, please visit the BlackOffers.com Newsletters Subscribe Me mailing list at our website: http://www.mybmail.com to add yourself automatically, or click on the link below to automatically re-subscribe yourself: http://mybmail.com/cgi-bin/info/s.pl?a=1l=16e=current=:freebsd.org Thank you, BlackOffers.com Newsletters To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any chance of release patch being committed?
J Wunsch wrote: Terry Lambert [EMAIL PROTECTED] wrote: Isn't anyone but me and Walnut Creek cum BSDI cum Windriver Systems using make release?!? We are, but why would we use anything else than GENERIC for it, seriously? I'd never roll a `release' for my current machine. Examples abound: 1) Licensed commercial drivers not present in GENERIC 2) Cut down kernel for low memory systems 3) Kernel without support for 686/586/386 in an embedded system 4) Kernel without most of the disk controllers, e.g. a Compaq-specific Jump Start disk for FreeBSD Etc. It shouldn't matter anyway; it doesn't change the normal default sysinstall behaviour, image, or image size at all (the image is identical), unless KERNCONF is overridden. If that's so unreasonable, I suggest you remove the ? before the = in /usr/src/release/Makefile in the KERNCONF assignment, which looks like: KERNCONF?=GENERIC Since it makes damn little sense to allow it to be overridden, if the resulting CDROM will fail to install /kernel, and the resulting system will not be able to boot without an explict load kernel.MYKERNEL command to the boot loader. Doing that would reduce functionality; making my change would increase it... but make one or the other of them, please: in it's current state, the code _pretends_ that an override will work, when it will not. I hate code that lies to me, even if by omission; don't you? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: isdn stops working when load increases
On 3 Mai, Jens Schweikhardt wrote:
# However, as soon as I do a find / or buildworld or some other
# commands increasing the load significantly (about 1 or more),
# isdnd seems to take a nap. No more packets transmitted. If I
# suspend the running programs, isdnd awakes and continues.
# Is anybody else observing the same behavior?
#
# Not with my Apr 29 kernel (no rtprio keyword in isdnd.rc), at least I
# didn't noticed it.
#
# BTW: What about dial-on-demand?
Still ok. I have rtprio 25 (as from the isdnd.rc.sample, should I tune this?
Remove the line?) in my isdnd.rc and this at the end of /etc/rc.isdn:
I think Hellmuth choosed a good value for rtprio, and I didn't think it
solves your problem if you increase the value, but feel free to play a
little bit with it (I think isdnd slowes down because of a lot of
interrupts, and if I didn't have a wrong understanding of the system,
rtprio didn't helps in this case).
echo 'removing previous isp0 config'
ifconfig isp0 delete -link1 down
echo 'setting sppp options'
ispppcontrol isp0 myauthproto=pap myauthname= myauthsecret=
hisauthproto=none callin
echo 'configuring isp0'
ifconfig isp0 1.2.3.4 5.6.7.8 netmask 0x link1 2/dev/null
What's your defaultroute? I use -interface isp1.
BTW: I use /etc/start_if.isp1 to configure the interface, no need to
modify rc.isdn, e.g.:
---snip---
(11) root@ttyp0 # less /etc/start_if.isp1
ifconfig isp1 link1 0.0.0.0 0.0.0.1 netmask 255.255.0.0
ispppcontrol isp1 $(cat /etc/isdn/connect-CBC.parameters) enable-vj
ifconfig isp1 down
---snip---.
While we're at it, maybe someone wants to commit something like this:
---snip---
--- /usr/src/etc/rc.isdnSat Apr 28 14:49:22 2001
+++ /etc/rc.isdnSun Apr 29 15:37:04 2001
@@ -38,6 +38,23 @@
[Yy][Ee][Ss])
echo -n 'ISDN subsystem setup:'
+ # Terminal type for fullscreen mode, default to syscons driver
+ #
+ if [ ! -n ${isdn_ttype} ]; then
+ isdn_ttype=cons25
+ fi
+ if [ -n ${isdn_screenflags} ]; then
+ /usr/sbin/vidcontrol ${isdn_fsdev} ${isdn_fsdev} 21
+${isdn_screenflags}
+ fi
+
+ # Check for pcvt driver (VT100/VT220 emulator)
+ #
+ if [ -x /usr/sbin/ispcvt ]; then
+ if /usr/sbin/ispcvt; then
+ isdn_ttype=pcvt25
+ fi
+ fi
+
case ${isdn_flags} in
[Nn][Oo])
isdn_flags=''
---snip---
(I think the isdn_ttype part isn't needed anymore, someone committed
something like this already, but the screenflags part is useful for me)
Bye,
Alexander.
--
Loose bits sink chips.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Any chance of release patch being committed?
tlambert2 Examples abound:
All of examples are just we want yet another *generic* kernel for
specific machines.
Why you don't replace src/sys/${arch}/conf/GENERIC file to your own
(customized) version? It is too simple, and matches your requirements.
-- -
Makoto `MAR' MATSUSHITA
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
On Wed, 2 May 2001, Daniel Eischen wrote: On Wed, 2 May 2001, Bruce Evans wrote: I am planning on using %fs for TSD/KSD and want it to be valid in signal handlers. Imagine doing the same thing with %ds, or better yet, %ss. %ss must be set to the default for the kernel to even provide a normal stack for the signal handler. Similarly for %ds, except it is possible for signal handlers to set up their own %ds as necessary provided both the user code and the signal trampoline is written to avoid using %ds before initializing it. Well, we're not using %ds or %ss for TSD. It was discussed on Someone else might :-). -arch some time ago that we would reserve %fs for TSD, so we really on care about that case. I threw in %gs because that was also an option except that WINE used it. [ patch snipped ] There is also the osendsig() case, and corresponding code in several emulators. I don't think we care too much about osendsig() since anything that uses a new threads library will have to be recompiled and wouldn't use the old routines. I think the same is true for emulators; an application that used the new threads library wouldn't be running in emulation would it? A library running under an emulator might. Non-emulated Linux seems to pass %fs and %gs to signal handlers unchanged, so there is a precedent for doing things like you want. Go ahead. The Linux emulator certainly needs to do it the same as Linux. So, what if we just make the change for %fs. Or is there a way to tell the kernel Hey, I don't want %fs to be changed when setting up the signal handler? A flag to sigaction sa_flags? The other option is for the userland signal handler to fetch the value for %fs out of the sigcontext^Wucontext and manually set it. But this gets icky because now the threads library has to have arch-dependent signal handlers. Setting arch-dependent sigaction flags might be icky too. Add some later if the default behaviour causes problems. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lockup after resume
On Mon, Apr 09, 2001 at 11:10:54AM +0200, Dag-Erling Smorgrav wrote: Georg-W. Koltermann [EMAIL PROTECTED] writes: I am experiencing a strange lockup with -current as of about a week ago: It will suspend and resume, but after the resume the console is dead and the system hangs after a short while. I'm seeing this too on my laptop. Used to work fine, no longer does. I'll try the latest greatest and see if the problem goes away. DES Dag-Erling, I CVSuped twice since my initial report, and the problem is still there. On the other hand I have a report from David Wolfskill that suspend/resume works fine for him. a) Does suspend/resume now work for you? b) What hardware/firmware do you have (mine is a DELL Inspiron 7500 with BIOS rev A12)? c) David, since it seems to work for you, what hardware/firmware do you have? One surprising observation: If I disable APM in /boot/device.hints, my machine suspends and resumes JUST FINE. The BIOS alone seems to be able to suspend and awake the hardware behind FreeBSD's back. The system only hangs if FreeBSD is involved in the process. -- Regards, Georg. -- Who in the world needs 2000 Windows? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lockup after resume
Date: Fri, 4 May 2001 14:39:12 +0200 From: Georg-W. Koltermann [EMAIL PROTECTED] I CVSuped twice since my initial report, and the problem is still there. On the other hand I have a report from David Wolfskill that suspend/resume works fine for him. Right. c) David, since it seems to work for you, what hardware/firmware do you have? It's similar to a Dell Inspiron 5000e (I suspect it's made by the same folks). http://www.catwhisker.org/~david/FreeBSD/laptop.html for more detail than folks are likely to want (though it does include a link to a floppy image that I used to update the BIOS; note that said BIOS claims to be for either my (type of) machine or a Dell Inspiron 5000e). One surprising observation: If I disable APM in /boot/device.hints, my machine suspends and resumes JUST FINE. The BIOS alone seems to be able to suspend and awake the hardware behind FreeBSD's back. The system only hangs if FreeBSD is involved in the process. Curiouser and curiouser Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any chance of release patch being committed?
On Fri, 04 May 2001 20:38:06 +0900, Makoto MATSUSHITA wrote:
All of examples are just we want yet another *generic* kernel for
specific machines.
Why you don't replace src/sys/${arch}/conf/GENERIC file to your own
(customized) version? It is too simple, and matches your requirements.
Because that's a repo-backed file. Why make me manage CVS conflicts on
update? Why not just allow something like RELEASE_KERNCONF? What's the
real objection to it? So far, all I've heard is Gee, I've never needed
that. :-)
Ciao,
Sheldon.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: isdn stops working when load increases
On Wed, May 02, 2001 at 09:03:26PM +0200, Jens Schweikhardt wrote: Hello, I've seen some recent mails related to rtprio oddity which seemed to also affect the isdnd. My -current is cvsupped May 1st (and survived; I've still got a fully populated root fs :-) However, as soon as I do a find / or buildworld or some other commands increasing the load significantly (about 1 or more), isdnd seems to take a nap. No more packets transmitted. If I suspend the running programs, isdnd awakes and continues. Is anybody else observing the same behavior? I'm having similar problems: Some minutes/hours (depends on the workload) after each boot 'top' reports about 12% of my CPU time are used for interrupt processing. The interrupt time stays at about 10% even when there's nothing to do (no disk io, no network traffic, no sound). Running FBSD 4.2 on the same box reports about 0.2-1% interrupt usage; the same value which is shown on CURRENT just after a reboot. At the same time the packet loss rate of my isdn interface raises to about 70% while transfering files. (a simple ping does *not* trigger this problem). This behavior seems not related to rtprio oddity since i first noticed it on Apr 9th. (the date this box switched to CURRENT) joerg To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lockup after resume
Georg-W. Koltermann [EMAIL PROTECTED] writes: a) Does suspend/resume now work for you? No, but I haven't upgraded my kernel since right before Easter. b) What hardware/firmware do you have (mine is a DELL Inspiron 7500 with BIOS rev A12)? IBM ThinkPad 600E, don't remember the firmware revision but it's very recent. One surprising observation: If I disable APM in /boot/device.hints, my machine suspends and resumes JUST FINE. The BIOS alone seems to be able to suspend and awake the hardware behind FreeBSD's back. The system only hangs if FreeBSD is involved in the process. Hmm, I might try that. BTW, last time I asked Warner about this his reply was (I paraphrase) it's not supposed to work, and if it ever worked for you it was out of sheer luck, which I find surprising. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-CURRENT buildworld broken....
In: stage 4: make dependencies ... === secure/usr.bin/ssh-keyscan rm -f .depend mkdep -f .depend -a-DNO_IDEA -I/usr/obj/usr/src/i386/usr/include /usr/src/secure/usr.bin/ssh-keyscan/../../../crypto/openssh/ssh-keyscan.c cd /usr/src/secure/usr.bin/ssh-keyscan; make _EXTRADEPEND echo ssh-keyscan: /usr/obj/usr/src/i386/usr/lib/libc.a /common/C/obj/usr/src/secure/usr.bin/ssh-keyscan/../../lib/libssh/libssh.a /usr/obj/usr/src/i386/usr/lib/libcrypto.a .depend === secure/usr.sbin === secure/usr.sbin/sshd make: don't know how to make pty.c. Stop *** Error code 2 Stop in /usr/src/secure/usr.sbin. *** Error code 1 Stop in /usr/src/secure. *** Error code 1 Recent CVSup history: CVSup begin from cvsup14.freebsd.org at Wed May 2 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 2 03:53:01 PDT 2001 CVSup begin from cvsup14.freebsd.org at Thu May 3 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Thu May 3 03:52:25 PDT 2001 CVSup begin from cvsup14.freebsd.org at Thu May 3 15:31:18 PDT 2001 CVSup ended from cvsup14.freebsd.org at Thu May 3 15:36:51 PDT 2001 CVSup begin from cvsup14.freebsd.org at Fri May 4 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Fri May 4 03:53:47 PDT 2001 uname: FreeBSD m133.whistle.com 5.0-CURRENT FreeBSD 5.0-CURRENT #52: Thu May 3 18:52:06 PDT 2001 root@localhost:/common/C/obj/usr/src/sys/LAPTOP_30W i386 [What was that that Kris wrote about turbulence on this flight...? :-)] Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
In article [EMAIL PROTECTED], Robert Watson [EMAIL PROTECTED] wrote: I think we can all take lessons from phk here -- he achieves a level of destructiveness that makes even the pro's marvel in wonder. Your criticism is grossly unfair. Throughout the very long time he's been active in this project, PHK's contribution/breakage ratio has been unsurpassed. 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: Any chance of release patch being committed?
On 04-May-01 Sheldon Hearn wrote: On Fri, 04 May 2001 00:00:58 +0200, J Wunsch wrote: We are, but why would we use anything else than GENERIC for it, seriously? I'd never roll a `release' for my current machine. When you get commitment to a fixed hardware configuration for two years and you want to leave your datacenter full of hosts ready to power up and play off a custom CDROM, a release that uses a custom kernel is desirable. That said, I don't think that the release should pick up KERNCONF. I think a middle-ground option is to have the release pick up RELEASE_KERNCONF. That is fine, but do note that Terry didn't add a new KERNCONF variable, it was already called that to begin with. We don't use buildkernel/installkernel in release, so it doesn't actually cause any conflicts. But anyways. Anyone have any reasonable objections to Terry's patch? If not I'll test it out for sanity and then commit it. Ciao, Sheldon. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
FW: Snapshot Log - world broken
=== libpam/modules/pam_tacplus cc -O -pipe -Wall -I/usr/src/lib/libpam/modules/pam_tacplus/../../../../contrib/libpam/libpam/incl ude -I/usr/src/lib/libpam/mo dules/pam_tacplus/../../libpam -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libpam/modules/pam_tacplus/pam_tacplus.c -o pam_tacplus.o cc -fpic -DPIC -O -pipe -Wall -I/usr/src/lib/libpam/modules/pam_tacplus/../../../../contrib/libpam/libpam/incl ude -I/usr/src/l ib/libpam/modules/pam_tacplus/../../libpam -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libpam/modules/pam_tacplus/pam_t acplus.c -o pam_tacplus.So building static pam_tacplus library building shared library pam_tacplus.so ranlib libpam_tacplus.a === libpam/modules/pam_unix cc -O -pipe -Wall -I/usr/src/lib/libpam/modules/pam_unix/../../../../contrib/libpam/libpam/include -I/usr/src/lib/libpam/modul es/pam_unix/../../libpam -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libpam/modules/pam_unix/pam_unix.c -o pam_unix.o cc -fpic -DPIC -O -pipe -Wall -I/usr/src/lib/libpam/modules/pam_unix/../../../../contrib/libpam/libpam/include -I/usr/src/lib/ libpam/modules/pam_unix/../../libpam -I/usr/obj/usr/src/i386/usr/include -c /usr/src/lib/libpam/modules/pam_unix/pam_unix.c -o pam_unix.So building static pam_unix library building shared library pam_unix.so ranlib libpam_unix.a === libpam/libpam make: don't know how to make ../modules/pam_ssh/libpam_ssh.a. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error 1 error*** Error code 2 *** Error code 2 Stop in /usr/src/release. release started at 06:00:00 on 05/04/01 release died at 08:21:12 on 05/04/01 --End of forwarded message- -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
world broken (sshd)
It looks like world does not currently compile: some files have been removed from src/crypto/openssh/ a few hours ago, but are still listed in SRCS in secure/usr.sbin/sshd/Makefile. Possible workaround: --- secure/usr.sbin/sshd/Makefile.dist Fri May 4 17:10:19 2001 +++ secure/usr.sbin/sshd/Makefile Fri May 4 18:14:35 2001 @@ -5,8 +5,8 @@ PROG= sshd SRCS= sshd.c auth-rhosts.c auth-passwd.c auth-rsa.c auth-rh-rsa.c \ - pty.c log-server.c login.c servconf.c serverloop.c \ - auth.c auth1.c auth2.c auth-options.c session.c login_access.c dh.c \ + log-server.c servconf.c serverloop.c \ + auth.c auth1.c auth2.c auth-options.c session.c dh.c \ auth-pam.c MAN= sshd.8 -- Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED] ENST // 46 rue Barrault // 75634 PARIS CEDEX 13 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
John Polstra [EMAIL PROTECTED] wrote: Your criticism is grossly unfair. Throughout the very long time he's been active in this project, PHK's contribution/breakage ratio has been unsurpassed. And btw., the recent stdio breakage wasn't all that bad either, and it completely happened in userland. I ended up in reinstalling a system from backup tapes, so the effect is not different to the specfs bug. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Any chance of release patch being committed?
Sheldon Hearn [EMAIL PROTECTED] wrote: That said, I don't think that the release should pick up KERNCONF. I think a middle-ground option is to have the release pick up RELEASE_KERNCONF. That sounds best to me. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
In article [EMAIL PROTECTED] you wrote: In article [EMAIL PROTECTED], Robert Watson [EMAIL PROTECTED] wrote: I think we can all take lessons from phk here -- he achieves a level of destructiveness that makes even the pro's marvel in wonder. Your criticism is grossly unfair. Too much snipping; that wasn't critizism. It was pure jealousy. 8-) He also said obviously I haven't been playing in the right bits of the system, I'll have to start hacking the low-level stuff in FFS some more... And - who knows - it might be that phk's real middle name is Haegar 8-))). (Am I the only one making back up copies before make installkernel; make installworld?) Achim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
On Fri, 4 May 2001, Bruce Evans wrote: On Wed, 2 May 2001, Daniel Eischen wrote: On Wed, 2 May 2001, Bruce Evans wrote: There is also the osendsig() case, and corresponding code in several emulators. I don't think we care too much about osendsig() since anything that uses a new threads library will have to be recompiled and wouldn't use the old routines. I think the same is true for emulators; an application that used the new threads library wouldn't be running in emulation would it? A library running under an emulator might. Non-emulated Linux seems to pass %fs and %gs to signal handlers unchanged, so there is a precedent for doing things like you want. Go ahead. The Linux emulator certainly needs to do it the same as Linux. OK, thanks. Here's my guess at what should be changed for the Linux emulator. If this looks correct, I'll commit it. Hmm, I wonder how linuxthreads works under FreeBSD without this change... -- Dan Eischen Index: linux/linux_sysvec.c === RCS file: /home/ncvs/src/sys/i386/linux/linux_sysvec.c,v retrieving revision 1.78 diff -u -r1.78 linux_sysvec.c --- linux/linux_sysvec.c2001/05/01 08:12:52 1.78 +++ linux/linux_sysvec.c2001/05/04 22:49:41 @@ -338,8 +338,6 @@ regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; regs-tf_es = _udatasel; - regs-tf_fs = _udatasel; - load_gs(_udatasel); regs-tf_ss = _udatasel; } @@ -472,8 +470,6 @@ regs-tf_cs = _ucodesel; regs-tf_ds = _udatasel; regs-tf_es = _udatasel; - regs-tf_fs = _udatasel; - load_gs(_udatasel); regs-tf_ss = _udatasel; } To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
Daniel Eischen writes: OK, thanks. Here's my guess at what should be changed for the Linux emulator. If this looks correct, I'll commit it. Hmm, I wonder how linuxthreads works under FreeBSD without this change... Well, they've never worked perfectly, by any means. Perhaps this will improve the stability problems people have been reporting with the various linux jdks under FreeBSD/i386. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
On Fri, 4 May 2001, John Polstra wrote: In article [EMAIL PROTECTED], Robert Watson [EMAIL PROTECTED] wrote: I think we can all take lessons from phk here -- he achieves a level of destructiveness that makes even the pro's marvel in wonder. Your criticism is grossly unfair. Throughout the very long time he's been active in this project, PHK's contribution/breakage ratio has been unsurpassed. I think my sarcasm may have gotten lost in transit; please re-read the message with a big blinking Sarcasm Follows post-it note reattached. I have great respect for Poul-Henning's work, especially with regards to his expertise in the device and buffering mechanisms in FreeBSD. The degree to which this is the case will becomes more clear in the near future. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
