Xwrapper and xdm exited on signal 11
Hello, I CVSuped at Thu Jul 19 11:33:58 UTC 2001, and did make world. Then Xwrapper always exits on signal 11, and I cannot use X11 now. Jul 20 04:33:17 current /boot/kernel/kernel: pid 467 (Xwrapper), uid 0: exited on signal 11 Jul 20 16:16:01 current /boot/kernel/kernel: pid 656 (xdm), uid 0: exited on signal 11 (core dumped) Jul 20 16:16:27 current /boot/kernel/kernel: pid 677 (Xwrapper), uid 0: exited on signal 11 (core dumped) And the followings are backtraces of them: current# gdb xdm xdm.core (snip) Core was generated by `xdm'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/X11R6/lib/libXmu.so.6... (no debugging symbols found)...done. Reading symbols from /usr/X11R6/lib/libXt.so.6... (no debugging symbols found)...done. Reading symbols from /usr/X11R6/lib/libSM.so.6... (no debugging symbols found)...done. Reading symbols from /usr/X11R6/lib/libICE.so.6... (no debugging symbols found)...done. Reading symbols from /usr/X11R6/lib/libXext.so.6... (no debugging symbols found)...done. Reading symbols from /usr/X11R6/lib/libX11.so.6... (no debugging symbols found)...done. Reading symbols from /usr/lib/librpcsvc.so.2...(no debugging symbols found)... done. ---Type return to continue, or q return to quit--- Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols found)... done. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)... done. Reading symbols from /usr/lib/libxpg4.so.3...(no debugging symbols found)... done. Reading symbols from /usr/lib/compat/libc.so.4... (no debugging symbols found)...done. Reading symbols from /usr/X11R6/lib/libXThrStub.so.6... (no debugging symbols found)...done. Reading symbols from /usr/lib/pam_nologin.so...(no debugging symbols found)... done. Reading symbols from /usr/lib/pam_unix.so...(no debugging symbols found)... done. Reading symbols from /usr/lib/pam_deny.so...(no debugging symbols found)... done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)... done. #0 0x282391c0 in strcmp () from /usr/lib/compat/libc.so.4 (gdb) where #0 0x282391c0 in strcmp () from /usr/lib/compat/libc.so.4 #1 0x281a9aa6 in pam_std_option () from /usr/lib/libpam.so.1 #2 0x2826f816 in pam_sm_authenticate () from /usr/lib/pam_nologin.so #3 0x281abc69 in pam_getenvlist () from /usr/lib/libpam.so.1 #4 0x281abf6d in _pam_dispatch () from /usr/lib/libpam.so.1 #5 0x281ab2d8 in pam_authenticate () from /usr/lib/libpam.so.1 #6 0x805723c in Verify () #7 0x8056e65 in GreetUser () #8 0x8051c5e in ManageSession () #9 0x8050115 in StartDisplay () #10 0x804ff8e in WaitForChild () #11 0x804ee4c in ForEachDisplay () #12 0x804ffa3 in WaitForChild () #13 0x804f684 in main () #14 0x804cbf5 in _start () (gdb) q current# gdb Xwrapper Xwrapper.core (snip) Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)... done. Reading symbols from /usr/lib/libxpg4.so.3...(no debugging symbols found)... done. Reading symbols from /usr/lib/compat/libc.so.4... (no debugging symbols found)...done. Reading symbols from /usr/lib/pam_permit.so...(no debugging symbols found)... done. Reading symbols from /usr/lib/pam_nologin.so...(no debugging symbols found)... done. Reading symbols from /usr/lib/pam_unix.so...(no debugging symbols found)... done. Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols found)... done. ---Type return to continue, or q return to quit--- Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols found)... done. Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols found)... done. #0 0x280d61c0 in strcmp () from /usr/lib/compat/libc.so.4 (gdb) where #0 0x280d61c0 in strcmp () from /usr/lib/compat/libc.so.4 #1 0x28068aa6 in pam_std_option () from /usr/lib/libpam.so.1 #2 0x2810a782 in pam_sm_authenticate () from /usr/lib/pam_permit.so #3 0x2806ac69 in pam_getenvlist () from /usr/lib/libpam.so.1 #4 0x2806af6d in _pam_dispatch () from /usr/lib/libpam.so.1 #5 0x2806a2d8 in pam_authenticate () from /usr/lib/libpam.so.1 #6 0x804877d in main () #7 0x804869d in _start () (gdb) q My X11 binaries are XFree86 3.3.6, which was accompanied with 4.1-RELEASE CD-ROM. And, uname -a generates: FreeBSD current.my.domain 5.0-CURRENT FreeBSD 5.0-CURRENT #0: \ Fri Jul 20 03:39:33 JST 2001 \ [EMAIL PROTECTED]:/usr/obj/usr/src/sys/current i386 Does anyone have the same problem? koya To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xwrapper and xdm exited on signal 11
On Fri, Jul 20, 2001 at 04:27:39PM +0900, Yoshihiro Koya wrote: Hello, I CVSuped at Thu Jul 19 11:33:58 UTC 2001, and did make world. Then Xwrapper always exits on signal 11, and I cannot use X11 now. Rebuild them. Recent PAM changes broke binary compatibility within 5.0-CURRENT. Hopefully 4.x compatibility is still okay, but I haven't checked. Kris PGP signature
Re: Xwrapper and xdm exited on signal 11
On Fri, 20 Jul 2001, Yoshihiro Koya wrote: YKI CVSuped at Thu Jul 19 11:33:58 UTC 2001, and did make world. YKThen Xwrapper always exits on signal 11, and I cannot use X11 now. You need to recompile all ports using pam. See /usr/src/UPDATING. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xwrapper and xdm exited on signal 11
Hello, From: Kris Kennaway [EMAIL PROTECTED] Subject: Re: Xwrapper and xdm exited on signal 11 Date: Fri, 20 Jul 2001 00:45:58 -0700 On Fri, Jul 20, 2001 at 04:27:39PM +0900, Yoshihiro Koya wrote: Hello, I CVSuped at Thu Jul 19 11:33:58 UTC 2001, and did make world. Then Xwrapper always exits on signal 11, and I cannot use X11 now. Rebuild them. Recent PAM changes broke binary compatibility within 5.0-CURRENT. Hopefully 4.x compatibility is still okay, but I haven't checked. From: Harti Brandt [EMAIL PROTECTED] Subject: Re: Xwrapper and xdm exited on signal 11 Date: Fri, 20 Jul 2001 09:50:01 +0200 (CEST) On Fri, 20 Jul 2001, Yoshihiro Koya wrote: YKI CVSuped at Thu Jul 19 11:33:58 UTC 2001, and did make world. YKThen Xwrapper always exits on signal 11, and I cannot use X11 now. You need to recompile all ports using pam. See /usr/src/UPDATING. Thank you very much for your advices. When I posted the previous messages, I couldn't imagine that xdm and so on also use PAM. Now I am rebuilding them. Sorry for my redundant post. koya To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xwrapper and xdm exited on signal 11
Harti Brandt wrote: On Fri, 20 Jul 2001, Yoshihiro Koya wrote: YKI CVSuped at Thu Jul 19 11:33:58 UTC 2001, and did make world. YKThen Xwrapper always exits on signal 11, and I cannot use X11 now. You need to recompile all ports using pam. See /usr/src/UPDATING. Is there any extensive list of the ports that have a dependancy on libpam? I can tell this is gonna be a pain, but hey, that's -current... Such a list would be useful info... Possibly for other system libraries as well for future changes to -current. Just an idea, and I'm laying odds it would be a huge project to document system library dependancies for /usr/ports as a whole, but for -current, such info could be handy. I could volunteer some of my time, but honestly, I know I can't do it by myself if it hasn't been done yet. Maybe it could be documented by the port maintainers as to which system libraries a port uses as a standard procedure for adding a port to -current, possibly with a additional option to make search such as make search ldep=libpam for instance? IMHO, it would make -current less of a pain to deal with when fundamental library changes are made requiring ports to be recompiled. We all know that such things are bound to happen in -current, indeed they must, but anything to make the transition easier at the policy level would help! Maybe we can get a team of people that can document such dependancies for future transistions, contact the port maintainers for their help as available, and require such info for new ports? I would volunteer my time, short as it is, for such an endeavor. I've done -current for heck, five or six years now, and EVERY time small fundamental changes are made, small bits get missed in the transition, as well as it being a case of if it breaks, recompile it without asking why for the stuff that we all miss in such transitions because the program is only rarely used. I just tossing these out as suggestions, and I am offering to give what help I can to such a project. First, there must be a policy decision on the matter of port-inclusion requiring such a breakdown of system library dependancies, afterwards we should worry about how to do this. This goes beyond libpam into making life under -current, hard knocks as it is, at least much easier to deal with when small, but fundamental changes are made to the base libraries themselves. Once the initial work is done, it would be a simple matter of the port maintainer him or herself to do this. maybe under /usr/ports/category/port/files I don't know about the utility of this to -RELEASE and -STABLE, but I'm sure it could come in handy there as well, in case of CERT bulletins, etc, that require such small, but fundamental changes to libraries in the future on such platforms, and we all know that is a possibility at any time even under -RELEASE and -STABLE. This alone could justify it as a general FreeBSD ports inclusion requirement, and not just applicable to -current. Such documentation should originate in -current, and ultimately be left in when it becomes -RELEASE and -STABLE, thus back-porting the documentation and inclusion guidelines to 4.x may not be necessary. IMHO, this would solve one longstanding problem that -current has always had. This would also allow some form of security-related info [possibly using a package/port search utility] in the -RELEASE and STABLE version from 5.0-R onward for what needs to be replaced/recompiled if/when a serious security flaw is found in a system library and it gets fixed. Anyhow, back to the original question... Does such a list already exist for libpam? jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Xwrapper and xdm exited on signal 11
On Fri, 20 Jul 2001, Jim Bryant wrote: JBHarti Brandt wrote: JB JB On Fri, 20 Jul 2001, Yoshihiro Koya wrote: JB JB YKI CVSuped at Thu Jul 19 11:33:58 UTC 2001, and did make world. JB YKThen Xwrapper always exits on signal 11, and I cannot use X11 now. JB JB You need to recompile all ports using pam. See /usr/src/UPDATING. JB JBIs there any extensive list of the ports that have a dependancy on libpam? [SNIP] A doubt that it will be possible to maintain such a list. However you could use something like for i in /bin /usr/bin /usr/local/bin /usr/X11R6/bin ; do ldd -f '%a %o\n' $i/* done 2/dev/null | grep libpam to get a list of binaries which depend on libpam. I'm not sure how to find out which shared libraries depend on libpam, ldd shared-object.so does not work. harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
netscape port fails to 'make install' after update to current?
After upgrading to -current from 4.3 on alpha, netscape dumps core, rebuilding port gives: 'make install' fails at: exception system: exiting due to internal error: out of memory trying to allocate exception system resources. What do i need to rebuild in ports directory first? -Mel To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [acpi-jp 1168] Re: HEADS UP - more ACPI updates, CPU throttling
Hi. Munehiro Matsuda [EMAIL PROTECTED] wrote: I'm also having same hang-up, with acpi_pcib.c rev1.10 (no NEWCARD). With acpi_pcib.c rev1.9, I loose my pccard. With acpi_pcib.c rev1.8, everything seems ok. From: [EMAIL PROTECTED] Date: Mon, 09 Jul 2001 18:51:12 +0900 ::I cvsup'ed to FreeBSD-current after this change, but I cannot boot ::kernel configured with device acpica (added to NEWCARD). ::I can boot with the configuration NEWCARD. ::In past days(cvsup'ed about 1-2 weeks ago), I was able to boot with ::device acpica. :: ::Machine: sony PCG-C1VSX/K :: ::Boot process stops at :: :: ::pci0: bridge, PCI-unknown at 7.3 (no driver attached) ::pci0: serial bus, FireWire at 8.0 (no driver attached) ::pci0: multimedia, audio at 9.0 (no driver attached) ::pci0: simple comms at 10.0 (no driver attached) ::pci0: multimedia at 11.0 (no driver attached) ::pccbb0: RF5C475 PCI-CardBus Bridge at device 12.0 on pci0 ::pccbb0: PCI Memory allocated: 4400 ::acpi_pcib0: matched entry for 0.12.INTA (source \_SB_.LINKB) ::acpi_pcib0: possible interrupts: 9 In my case, pcic_pcib.c rev 1.9 cause panic while booting. pcic_pcib.c rev 1.8 does work well for my machine too. Machine: SONY PCG-C1VSX/K with 3Com 3CXFE575CT-JP -- Yoichi Nakayama [EMAIL PROTECTED] E-ken, Dept. of Physics, Nagoya University http://www.eken.phys.nagoya-u.ac.jp/~yoichi/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libedit replacement for libreadline
Erik Trulsson wrote: Peter MFC'ed it a few weeks ago. A few days ago is more like it. (cvs log lib/libcrypto/Makefile gives the following:) revision 1.24.2.4 date: 2001/07/16 03:28:26; author: peter; state: Exp; lines: +11 -56 MFC: unify libscrypt/libdescrypt into libcrypt. Thanks; good to see that what I was seeing was true when I first responded in this thread, and that Peter was very conscientious in correcting the oversight. I think there are a number of ports libraries that do the same thing, however, so Garrance not withstanding, I still think it would be a good idea to follow the initial crypt example: use a symlink for libreadline, which can be optionally overridden by a user who wants to do it. I think there is real value in being able to use vinum tools in the absence of a mounted /usr, without causing vinum to be GPL'ed. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
huh? in Selrecord(): what is this for?
void
selrecord(selector, sip)
struct proc *selector;
struct selinfo *sip;
{
struct proc *p;
pid_t mypid;
mypid = selector-p_pid;
if (sip-si_pid == mypid)
return;
if (sip-si_pid (p = pfind(sip-si_pid))) {
Why do we look up 'p' when we got it as an argument?
(race condition detection?)
(I'm modifying things for threads so I came up against this)
mtx_lock_spin(sched_lock);
if (p-p_wchan == (caddr_t)selwait) {
mtx_unlock_spin(sched_lock);
PROC_UNLOCK(p);
sip-si_flags |= SI_COLL;
return;
}
mtx_unlock_spin(sched_lock);
PROC_UNLOCK(p);
}
sip-si_pid = mypid;
}
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: huh? in Selrecord(): what is this for?
Never mind.. I'm an ijut...
Julian Elischer wrote:
void
selrecord(selector, sip)
struct proc *selector;
struct selinfo *sip;
{
struct proc *p;
pid_t mypid;
mypid = selector-p_pid;
if (sip-si_pid == mypid)
return;
if (sip-si_pid (p = pfind(sip-si_pid))) {
Why do we look up 'p' when we got it as an argument?
(race condition detection?)
(I'm modifying things for threads so I came up against this)
mtx_lock_spin(sched_lock);
if (p-p_wchan == (caddr_t)selwait) {
mtx_unlock_spin(sched_lock);
PROC_UNLOCK(p);
sip-si_flags |= SI_COLL;
return;
}
mtx_unlock_spin(sched_lock);
PROC_UNLOCK(p);
}
sip-si_pid = mypid;
}
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
--
++ __ _ __
| __--_|\ Julian Elischer | \ U \/ / hard at work in
| / \ [EMAIL PROTECTED] +--x USA\ a very strange
| ( OZ)\___ ___ | country !
+- X_.---._/presently in San Francisco \_/ \\
v
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: huh? in Selrecord(): what is this for?
On 20-Jul-01 Julian Elischer wrote:
void
selrecord(selector, sip)
struct proc *selector;
struct selinfo *sip;
{
struct proc *p;
pid_t mypid;
mypid = selector-p_pid;
if (sip-si_pid == mypid)
return;
if (sip-si_pid (p = pfind(sip-si_pid))) {
Why do we look up 'p' when we got it as an argument?
(race condition detection?)
Err, we look up p when the selector pid isn't the pid in the selinfo. I.e.,
when we _didn't_ get p as an argument.
--
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
Re: -current kernel hangs?
Date: Fri, 20 Jul 2001 10:57:02 +0700 (NOVST) From: [EMAIL PROTECTED] With a July 18, 2001 sources, it seems like the kernel hands at the entropy harvesting stage ctrl-t shows: Also (again, for me) sysctl -N -a outputs a (non-terminating) stream of ... I have some kind of workaround (see the patch). In my config without this patch 'sysctl -a' hungs at net.inet.accf and with this patch it successfully run up to the end. I can not see what is wrong with the lines disabled by the patch. After building today's -CURRENT OK (and observing that the behavior was still the same for my custom kernel), I tried building a GENERIC kernel. Much to my surprise (and different from my experience on 06 July -- last time I had built a GENERIC kernel for -CURRENT), that kernel did not exhibit the symptoms. I've now managed to circumvent the problem by: * Removing the device pcm specification in my custom kernel config. * Adding the lines snd_pcm_load=YES snd_maestro_load=YES to /boot/loader.conf * Re-building the kernel. (cd /usr/src; make kernel KERNCONF=LAPTOP_30W) * Re-booting. It took a few tries to get things quite right, but sound works again; thanks to the patch in http://www.FreeBSD.org/cgi/query-pr.cgi?pr=26854, I'm (still) able to use the keyboard Fn+End chord to mute the sound during boot (so that process is less disruptive in meetings). (BTW, it would be nice to get that tiny little patch in before 4.4-R. Please?) And yes, Linux emulation still works. 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
[Patch] ACPI support in rc.conf
Hi,
attached is a diff for rc.i386, rc.conf.5 and defaults/rc.conf which
allows to enable the ACPI power management in rc.conf similar to
apm_enable.
It also removes a reference to the non existing acpi(9) from acpi(4).
Bye,
Alexander.
--
Reboot America.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
Index: etc/defaults/rc.conf
===
RCS file: /big/FreeBSD-CVS/src/etc/defaults/rc.conf,v
retrieving revision 1.117
diff -u -r1.117 rc.conf
--- etc/defaults/rc.conf2001/07/17 14:33:52 1.117
+++ etc/defaults/rc.conf2001/07/20 19:25:46
@@ -20,6 +20,7 @@
##
swapfile=NO # Set to name of swapfile if aux swapfile desired.
+acpi_enable=NO # Set to YES to enable ACPI BIOS functions (or NO).
apm_enable=NO# Set to YES to enable APM BIOS functions (or NO).
apmd_enable=NO # Run apmd to handle APM event from userland.
apmd_flags= # Flags to apmd (if enabled).
Index: etc/etc.i386/rc.i386
===
RCS file: /big/FreeBSD-CVS/src/etc/etc.i386/rc.i386,v
retrieving revision 1.58
diff -u -r1.58 rc.i386
--- etc/etc.i386/rc.i3862001/01/09 22:28:17 1.58
+++ etc/etc.i386/rc.i3862001/07/20 19:23:04
@@ -6,6 +6,13 @@
echo -n 'Initial rc.i386 initialization:'
+case ${acpi_enable} in
+[Yy][Ee][Ss])
+ echo -n ' acpi'
+ acpiconf -e /dev/null 21
+ ;;
+esac
+
case ${apm_enable} in
[Yy][Ee][Ss])
echo -n ' apm'
Index: share/man/man4/acpi.4
===
RCS file: /big/FreeBSD-CVS/src/share/man/man4/acpi.4,v
retrieving revision 1.2
diff -u -r1.2 acpi.4
--- share/man/man4/acpi.4 2001/07/06 08:10:59 1.2
+++ share/man/man4/acpi.4 2001/07/20 19:36:15
@@ -256,8 +256,7 @@
.Sh COMPATIBILITY
ACPI is only found/supported on Intel platforms (i386/IA32 and IA64).
.Sh SEE ALSO
-.Xr config 8 ,
-.Xr acpi 9
+.Xr config 8
.Sh AUTHORS
.An -nosplit
The ACPI CA subsystem is developed and maintained by
Index: share/man/man5/rc.conf.5
===
RCS file: /big/FreeBSD-CVS/src/share/man/man5/rc.conf.5,v
retrieving revision 1.113
diff -u -r1.113 rc.conf.5
--- share/man/man5/rc.conf.52001/07/17 14:33:52 1.113
+++ share/man/man5/rc.conf.52001/07/20 19:31:16
@@ -78,12 +78,18 @@
.Dq NO
then no swapfile is installed, otherwise the value is used as the full
pathname to a file to use for additional swap space.
+.It Va acpi_enable
+.Pq Vt bool
+If set to
+.Dq YES ,
+enable support for ACPI power management support with the
+.Xr acpiconf 8
+command.
.It Va apm_enable
.Pq Vt bool
If set to
.Dq YES ,
-enable support for Automatic Power Management with
-the
+enable support for Automatic Power Management with the
.Xr apm 8
command.
.It Va apmd_enable
RE: [Patch] ACPI support in rc.conf
On 20-Jul-01 Alexander Leidinger wrote: Hi, attached is a diff for rc.i386, rc.conf.5 and defaults/rc.conf which allows to enable the ACPI power management in rc.conf similar to apm_enable. It also removes a reference to the non existing acpi(9) from acpi(4). It should probably replace acpi(9) with acpiconf(8). It was probably a typo for acpi(8) to begin with. -- 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
Re: acpica malfunctions
These are known bugs, and should be fixed in the next ACPI CA import (hopefully sometime in the next few days). I don't suppose this is going to fix the problem with the CUSL-2 BIOS ... -- Michael D. Harnois[EMAIL PROTECTED] Redeemer Lutheran Church Washburn, Iowa No excellent soul is exempt from a mixture of madness. -- Aristotle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
The whole libc FILE/stdio mess and 5.0
Were we going to do anything to get rid of: #define stdin (__sF[0]) #define stdout (__sF[1]) #define stderr (__sF[2]) for 5.0-release, or is the current fix the one we want to go with. I don't know if we ever decided how it should be properly fixed, or if it should be fixed at all. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The whole libc FILE/stdio mess and 5.0
* Daniel Eischen [EMAIL PROTECTED] [010720 17:00] wrote: Were we going to do anything to get rid of: #define stdin (__sF[0]) #define stdout (__sF[1]) #define stderr (__sF[2]) for 5.0-release, or is the current fix the one we want to go with. I don't know if we ever decided how it should be properly fixed, or if it should be fixed at all. considering the recent breakage wrt to PAM i'm more than happy to apply a diff to fix this. flamage will be repsonded to in my usual manner and we'll have the problem fixed. please submit patches. -- -Alfred Perlstein [[EMAIL PROTECTED]] Ok, who wrote this damn function called '??'? And why do my programs keep crashing in it? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: The whole libc FILE/stdio mess and 5.0
On Fri, 20 Jul 2001, Alfred Perlstein wrote: * Daniel Eischen [EMAIL PROTECTED] [010720 17:00] wrote: Were we going to do anything to get rid of: #define stdin (__sF[0]) #define stdout (__sF[1]) #define stderr (__sF[2]) for 5.0-release, or is the current fix the one we want to go with. I don't know if we ever decided how it should be properly fixed, or if it should be fixed at all. considering the recent breakage wrt to PAM i'm more than happy to apply a diff to fix this. flamage will be repsonded to in my usual manner and we'll have the problem fixed. please submit patches. Well, peter attempted this in version 1.29 of stdio.h, but the impact was too great at the time. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
usr.bin/write/write.c patch
Hello - I patched up write.c a bit. 1. Constified 2. Changed a strncpy to strlcpy 3. change S_IWRITE 3 to S_IWGRP 4. Changed fileno(stdin/stdout/stderr) to STD*_FILENO 5. cleaned up 2 pieces of code so it will compile when WARNS=2 is set. The patch is attached, and can be found at http://www.phobia.ms/patches/write.c.20072001.diff Any comments? - David Hill write.c.20072001.diff
Re: [Patch] ACPI support in rc.conf
attached is a diff for rc.i386, rc.conf.5 and defaults/rc.conf which allows to enable the ACPI power management in rc.conf similar to apm_enable. This is not a good idea; ACPI isn't on or off, and by the time rc.conf is running it's too late to en/disable it. There are several seperate policy items that need to be tweaked, and ideally the policy daemon will autodetect ACPI and quit if it's not supported, so it would be on all the time. It also removes a reference to the non existing acpi(9) from acpi(4). Please don't do this; it's there specifically as a goad to me to write acpi(9), which I'm trying to get to sooner rather than later. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Official America's Cup Jubilee Announcement
WASHINGTON PROMOTIONS INTERNATIONAL HONORED BY THE AMERICA'S CUP JUBILEE 2001 The America's Cup Jubilee Governing Committee in Cowes, United Kingdom has selected Washington Promotions International as the official U.S.A. merchandise licensee for the 150th Anniversary of the America's Cup. Please visit this web site to see the array of clothing, compasses, barometers and other commemorative items. http://wpi2001.com/index2.html Individuals, yacht and sailing clubs, and corporations everywhere, currently have the opportunity to acquire special items with ACJ2001 logo. Additionally, you may also choose to add your own logo to these fine items. This is a once in a lifetime opportunity to celebrate an event of this caliber and prestige. Please post to your newsletter or bulletin board. If you have any questions contact: Vassil C. Yanco (281)292-9810 Office (281)292-9331 Fax E-mail: [EMAIL PROTECTED] Web Site: http://wpi2001.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current kernel hangs?
On 19 Jul, Vincent Poy wrote: I didn't see this behavior. If somebody wants the output of a verbose boot, my kernel config or something else feel free to contact me. Hmmm, which kernel config did you use? I tried GENERIC and even Kernel config and loader.conf attached (accf is loaded by the loader, it isn't compiled into the kernel). Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 machine i386 ident WORK maxusers40 makeoptions DEBUG=-g makeoptions CONF_CFLAGS=-fno-builtin hints WORK.hints options PQ_CACHESIZE=128 cpu I686_CPU options CPU_FASTER_5X86_FPU options CPU_SUSP_HLT options NO_F00F_HACK options CPU_UPGRADE_HW_CACHE options PERFMON options COMPAT_43 options SYSVSHM options SYSVSEM options SYSVMSG options DDB options KTRACE options UCONSOLE options INET device ether device sppp device loop1 device bpf options INVARIANTS options INVARIANT_SUPPORT options DIAGNOSTIC options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options FFS options SOFTUPDATES options ENABLE_VFS_IOOPT options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L device scbus device da device cd device pass device ses options CAM_MAX_HIGHPOWER=4 options SCSI_DELAY=5000 options SES_ENABLE_PASSTHROUGH device pty device gzip options MSGBUF_SIZE=40960 device isa options PPS_SYNC device atkbdc 1 device atkbd options ATKBD_DFLT_KEYMAP makeoptions ATKBD_DFLT_KEYMAP=german.iso options KBD_INSTALL_CDEV device psm device vga device splash device sc 1 options MAXCONS=16 options SC_DFLT_FONT makeoptions SC_DFLT_FONT=iso options SC_HISTORY_SIZE=800 device npx device ata device atadisk device atapifd device fdc device sio 2 device ed device miibus device pca device apm device pci device ahc options AHC_ALLOW_MEMIO device smbus device intpm device smb device iicbus device iicbb device ic device iic device iicsmb options AVM_A1 device isic device i4bq921 device i4bq931 device i4b device i4btrc 2 device i4bctl device i4brbch 2 options IPR_VJ device i4bisppp 2 options PERIPH_1284 device ppbus device lpt device ppi device pps device lpbb device pcfclock options PPC_PROBE_CHIPSET device ppc options CLK_USE_TSC_CALIBRATION device random options VESA options MSDOSFS options PROCFS autoboot_delay=3 cd9660_load=YES vn_load=YES linux_load=YES usb_load=YES udbp_load=NO ugen_load=NO uhid_load=NO ukbd_load=NO ulpt_load=NO ums_load=NO umass_load=NO umodem_load=NO uscanner_load=NO agp_load=YES accf_data_load=YES accf_http_load=YES joy_load=YES snd_pcm_load=YES snd_sbc_load=YES snd_sb16_load=YES atspeaker_load=YES
Re: Xwrapper and xdm exited on signal 11
On Fri, 20 Jul 2001, Yoshihiro Koya wrote: I CVSuped at Thu Jul 19 11:33:58 UTC 2001, and did make world. Then Xwrapper always exits on signal 11, and I cannot use X11 now. Everything linked to libpam.so.1 was broken by recent changes in libpam. The pam modules that go with libpam.so.2 are incompatible with the ones that go with libpam.so.1. The latter were clobbered by the recent changes since they don't have version numbers. I work around this using the hack of replacing libpam.so.1 by a symlink to libpam.so.2. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: ACPI core code updated
I've just merged the Intel 20010717 code, after some very light testing at this end. Feedback is encouraged. The most visible change in this drop is a fix in handling of fields in unaligned regions; this should resolve the issue with Sony VAIO systems reporting bogus temperatures and AC adapter status (it may also have knock-on effects elsewhere). A few other minor changes were made in the OSPM portion of the code, mostly not user-visible. One major change; the acpi_timer code has been fleshed out into a complete timecounter. I will next be looking at the problems people are having with the PCI interrupt routing _SRS method failing. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
