ld-elf.so.1 broken with world from yesterday
Hi, yesterday I've made a new world. After booting it, ld-elf-so.1 complains about every library (libc, libutil, ...). My -current is not usable anymore because of this. Is this fixed in a recent snapshot, and if yes, is it enough to just replace ld-elf.so.1, or do I have to replace /usr/lib/ (too) to get a working -current? Bye, Alexander. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
i386 tinderbox failure
=== nge === nmdm === ntfs === nullfs === pcn === plip === portalfs === ppbus === ppi === pps === procfs === pseudofs === random === rl === rp === sf === sis === sk === sn === snp === sound === sound/pcm === sound/driver === sound/driver/als4000 === sound/driver/ad1816 === sound/driver/cmi === sound/driver/cs4281 === sound/driver/csa === sound/driver/ds1 === sound/driver/emu10k1 === sound/driver/es137x === sound/driver/ess === sound/driver/fm801 === sound/driver/ich === sound/driver/maestro === sound/driver/maestro3 === sound/driver/mss === sound/driver/neomagic === sound/driver/sb16 === sound/driver/sb8 === sound/driver/sbc === sound/driver/solo === sound/driver/t4dwave === sound/driver/via82c686 === sound/driver/vibes === sound/driver/driver === sppp === ste === sym === syscons === syscons/blank === syscons/daemon === syscons/dragon === syscons/fade === syscons/fire === syscons/green === syscons/logo === syscons/rain === syscons/snake === syscons/star === syscons/warp === syscons/apm === sysvipc === sysvipc/sysvmsg === sysvipc/sysvsem === sysvipc/sysvshm === ti === tl === twe === tx === txp === ucom === udbp === ufm === ugen === uhid === ukbd === ulpt === umapfs === umass === umodem === ums === unionfs /d/home/des/tinderbox/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:58: vm/vm_zone.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /d/home/des/tinderbox/src/sys/modules/unionfs. *** Error code 1 Stop in /d/home/des/tinderbox/src/sys/modules. *** Error code 1 Stop in /tmp/des/obj/i386/d/home/des/tinderbox/src/sys/GENERIC. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
Allerede fixet. In message [EMAIL PROTECTED], Dag-Erling Smorgrav writes: === nge === nmdm === ntfs === nullfs === pcn === plip === portalfs === ppbus === ppi === pps === procfs === pseudofs === random === rl === rp === sf === sis === sk === sn === snp === sound === sound/pcm === sound/driver === sound/driver/als4000 === sound/driver/ad1816 === sound/driver/cmi === sound/driver/cs4281 === sound/driver/csa === sound/driver/ds1 === sound/driver/emu10k1 === sound/driver/es137x === sound/driver/ess === sound/driver/fm801 === sound/driver/ich === sound/driver/maestro === sound/driver/maestro3 === sound/driver/mss === sound/driver/neomagic === sound/driver/sb16 === sound/driver/sb8 === sound/driver/sbc === sound/driver/solo === sound/driver/t4dwave === sound/driver/via82c686 === sound/driver/vibes === sound/driver/driver === sppp === ste === sym === syscons === syscons/blank === syscons/daemon === syscons/dragon === syscons/fade === syscons/fire === syscons/green === syscons/logo === syscons/rain === syscons/snake === syscons/star === syscons/warp === syscons/apm === sysvipc === sysvipc/sysvmsg === sysvipc/sysvsem === sysvipc/sysvshm === ti === tl === twe === tx === txp === ucom === udbp === ufm === ugen === uhid === ukbd === ulpt === umapfs === umass === umodem === ums === unionfs /d/home/des/tinderbox/src/sys/modules/unionfs/../../fs/unionfs/union_subr.c:58: vm/vm_zone.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /d/home/des/tinderbox/src/sys/modules/unionfs. *** Error code 1 Stop in /d/home/des/tinderbox/src/sys/modules. *** Error code 1 Stop in /tmp/des/obj/i386/d/home/des/tinderbox/src/sys/GENERIC. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- 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: Kernel debugging - what's the procedure?
On Sun, Apr 07, 2002 at 01:54:08PM -0700, Terry Lambert wrote: Josef Karthauser wrote: You use another machine, and connect the serial ports together. See the handbook for details. I'd love to ;) but no additional machine is available at the moment. Then you install vmware, and Julian's back-to-back serial driver, and then run the kernel to be debuged in the vmware session. This lets you debug the kernel on a virtual machine (single CPU only). Yes I do have vmware, but it's not going to help me debug the usb stack is it? (I know vmware3 does usb, but not if the underlying usb stack on the host machine is also hosed). If this is against a dead kernel, etiher your dump image is bad, or it doesn't match the kernel that made the dump. That's what I'd guess too, but the kernel that crashed is the same as the kernel that I'm debugging it on - I'm pretty sure: compiled today. Well, since this is the -current list... have you updated recently? There were some recent changes by PHK to the dump format that may have broken/fixed things, if your answer to that question is yes/no, respectively. Yes, that's what I implied by the above paragraph. I was up-to-date with sources yesterday. Joe msg37087/pgp0.pgp Description: PGP signature
Re: Problem with FreeBSD dc driver and Xircom PCMCIA card
Ah, finally someone else sees what I ran into last year. Look for my posting to -current in May 2001, subject dc0 ARP problem with CISCO. At that time, the only advice I got was to hardwire speed detection (which didn't help). My solution then was to switch hardware :-( So I'm afraid this is of no help to you, except for the mee too confirmation. -- Regards, Georg. Am Mi, 2002-03-27 um 21.47 schrieb Gavin Atkinson: [...snip...] It's starting to look promising. I even get a (red) link light on the card, and once an IP is configured, ifconfig can tell if the link exists or not, though cannot establish what the speed of it is (this is into a 100M switch). However, I still have almost no network connectivity with it. An outbound ping loses 100% of packets, and hosts trying to ping it cannot arp it's MAC address. However, once I have forced an entry into the arp table of the second host, I can ping the Xircom card, albeit very slowly (snipped down for clarity): PING epsilon.ury.york.ac.uk (10.0.0.109): 56 data bytes 64 bytes from 10.0.0.109: icmp_seq=211 ttl=64 time=2020.368 ms 64 bytes from 10.0.0.109: icmp_seq=216 ttl=64 time=3030.348 ms 64 bytes from 10.0.0.109: icmp_seq=217 ttl=64 time=2020.406 ms 64 bytes from 10.0.0.109: icmp_seq=223 ttl=64 time=2020.374 ms 64 bytes from 10.0.0.109: icmp_seq=229 ttl=64 time=2020.374 ms 64 bytes from 10.0.0.109: icmp_seq=253 ttl=64 time=7070.335 ms 64 bytes from 10.0.0.109: icmp_seq=255 ttl=64 time=5050.412 ms 64 bytes from 10.0.0.109: icmp_seq=286 ttl=64 time=6060.318 ms 64 bytes from 10.0.0.109: icmp_seq=287 ttl=64 time=5050.348 ms 64 bytes from 10.0.0.109: icmp_seq=288 ttl=64 time=4040.382 ms --- epsilon.ury.york.ac.uk ping statistics --- 311 packets transmitted, 139 packets received, 55% packet loss round-trip min/avg/max/stddev = 614.382/5760.691/9090.237/2161.803 ms Note the large mean time, and the fact that I consistantly lose 55% of packets. Watching the link light, the card seems to receive the packets instantly, buffer three or four, then lose the link. WHen the link comes back, the replies to these packets all get sent back at once. I'm now at a loss as to where to go. I have no idea how to progress with this, as i'm not a kernel hacker. Has anyone seen this before? If it helps, I am using revision 3 of the card (read using pci_read_config(dev, DC_PCI_CFRV, 4) 0xff), and it's on a Toshiba ToPIC 95B cardbus bridge. If anyone can help, i'd be most greatful... Thanks, Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c
On Sun, Apr 07, 2002 at 01:43:27PM -0700, Dag-Erling Smorgrav wrote: des 2002/04/07 13:43:27 PDT Modified files: lib/libpam/modules/pam_unix pam_unix.c Log: Fix bug in previous commit that passed the wrong default value to login_getcapstr(3). Also fix a longer-standing bug (login_close(3) frees the string returned by login_getcapstr(3)) by reorganizing the code a little, and use login_getpwclass(3) instead of login_getclass(3) if we already have a struct pwd. Sponsored by: DARPA, NAI Labs Revision ChangesPath 1.29 +8 -6 src/lib/libpam/modules/pam_unix/pam_unix.c This change also broke the Password: prompt. The bug is hidden by the -Wno-uninitialized setting in bsd.sys.mk. Here's the patch: %%% Index: pam_unix.c === RCS file: /home/ncvs/src/lib/libpam/modules/pam_unix/pam_unix.c,v retrieving revision 1.28 diff -u -p -r1.28 pam_unix.c --- pam_unix.c 6 Apr 2002 19:30:04 - 1.28 +++ pam_unix.c 8 Apr 2002 09:53:12 - @@ -122,7 +122,8 @@ pam_sm_authenticate(pam_handle_t *pamh, struct passwd *pwd; int retval; const char *pass, *user; - char *encrypted, *password_prompt; + char *encrypted; + const char *password_prompt; pam_std_option(options, other_options, argc, argv); @@ -141,7 +142,7 @@ pam_sm_authenticate(pam_handle_t *pamh, lc = login_getclass(NULL); password_prompt = login_getcapstr(lc, passwd_prompt, - password_prompt, NULL); + Password:, NULL); login_close(lc); lc = NULL; @@ -512,7 +513,8 @@ local_passwd(const char *user, const cha login_cap_t * lc; struct passwd *pwd; int pfd, tfd; - char *crypt_type, salt[SALTSIZE + 1]; + const char *crypt_type; + char salt[SALTSIZE + 1]; pwd = getpwnam(user); if (pwd == NULL) %%% But this patch won't work without the const poisoning lib/libutil: %%% Index: login_auth.c === RCS file: /home/ncvs/src/lib/libutil/login_auth.c,v retrieving revision 1.12 diff -u -p -r1.12 login_auth.c --- login_auth.c30 Sep 2001 22:35:07 - 1.12 +++ login_auth.c8 Apr 2002 09:58:59 - @@ -65,7 +65,7 @@ __FBSDID($FreeBSD: src/lib/libutil/logi void auth_checknologin(login_cap_t *lc) { - char *file; + const char *file; /* Do we ignore a nologin file? */ if (login_getcapbool(lc, ignorenologin, 0)) Index: login_cap.3 === RCS file: /home/ncvs/src/lib/libutil/login_cap.3,v retrieving revision 1.27 diff -u -p -r1.27 login_cap.3 --- login_cap.3 1 Oct 2001 16:09:18 - 1.27 +++ login_cap.3 8 Apr 2002 09:58:59 - @@ -52,12 +52,12 @@ .Fn login_getpwclass const struct passwd *pwd .Ft login_cap_t * .Fn login_getuserclass const struct passwd *pwd -.Ft char * -.Fn login_getcapstr login_cap_t *lc const char *cap char *def char *error +.Ft const char * +.Fn login_getcapstr login_cap_t *lc const char *cap const char *def const char +*error .Ft char ** .Fn login_getcaplist login_cap_t *lc const char *cap const char *chars -.Ft char * -.Fn login_getpath login_cap_t *lc const char *cap char *error +.Ft const char * +.Fn login_getpath login_cap_t *lc const char *cap const char *error .Ft rlim_t .Fn login_getcaptime login_cap_t *lc const char *cap rlim_t def rlim_t error .Ft rlim_t @@ -66,8 +66,8 @@ .Fn login_getcapsize login_cap_t *lc const char *cap rlim_t def rlim_t error .Ft int .Fn login_getcapbool login_cap_t *lc const char *cap int def -.Ft char * -.Fn login_getstyle login_cap_t *lc char *style const char *auth +.Ft const char * +.Fn login_getstyle login_cap_t *lc const char *style const char *auth .Ft const char * .Fn login_setcryptfmt login_cap_t *lc const char *def const char *error .Sh DESCRIPTION Index: login_cap.c === RCS file: /home/ncvs/src/lib/libutil/login_cap.c,v retrieving revision 1.26 diff -u -p -r1.26 login_cap.c --- login_cap.c 6 Mar 2002 15:24:51 - 1.26 +++ login_cap.c 8 Apr 2002 09:58:59 - @@ -344,8 +344,8 @@ login_getuserclass(const struct passwd * * an error string on error. */ -char * -login_getcapstr(login_cap_t *lc, const char *cap, char *def, char *error) +const char * +login_getcapstr(login_cap_t *lc, const char *cap, const char *def, const char *error) { char*res; intret; @@ -373,7 +373,7 @@ login_getcaplist(login_cap_t *lc, const if (chars == NULL) chars = , \t; -if ((lstring = login_getcapstr(lc, cap, NULL, NULL)) != NULL) +if ((lstring = (char *)login_getcapstr(lc, cap, NULL, NULL)) != NULL) return arrayize(lstring, chars, NULL); return NULL; } @@ -387,15 +387,15 @@ login_getcaplist(login_cap_t *lc, const * If there
Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c
Ruslan Ermilov [EMAIL PROTECTED] writes: On Sun, Apr 07, 2002 at 01:43:27PM -0700, Dag-Erling Smorgrav wrote: Log: Fix bug in previous commit that passed the wrong default value to login_getcapstr(3). Also fix a longer-standing bug (login_close(3) frees the string returned by login_getcapstr(3)) by reorganizing the code a little, and use login_getpwclass(3) instead of login_getclass(3) if we already have a struct pwd. This change also broke the Password: prompt. The bug is hidden by the -Wno-uninitialized setting in bsd.sys.mk. Here's the patch: The commit you quote *fixed* the bug you're referring to. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel debugging - what's the procedure?
Josef Karthauser wrote: On Sun, Apr 07, 2002 at 01:54:08PM -0700, Terry Lambert wrote: Josef Karthauser wrote: You use another machine, and connect the serial ports together. See the handbook for details. I'd love to ;) but no additional machine is available at the moment. Then you install vmware, and Julian's back-to-back serial driver, and then run the kernel to be debuged in the vmware session. This lets you debug the kernel on a virtual machine (single CPU only). Yes I do have vmware, but it's not going to help me debug the usb stack is it? (I know vmware3 does usb, but not if the underlying usb stack on the host machine is also hosed). It's my understanding that you can assign resources to the vmware machine, which it can then permit to be accessed natively. Thus, if you gave your USB ports to the vmware virtual machine entirely, this would resolve the problem. The vmware3 support for usb appears (to me) to be a tunnel driver, like the standard network driver interface (e.g. it pretends to be hardware, and uses a host driver to contact the real hardware, so that its use can be multiplexed and thus the device accessed by etiher the real or the virtual machine). Well, since this is the -current list... have you updated recently? There were some recent changes by PHK to the dump format that may have broken/fixed things, if your answer to that question is yes/no, respectively. Yes, that's what I implied by the above paragraph. I was up-to-date with sources yesterday. This is probably your problem. If you can back up to when the problem first appeared, or back out the kernel dump fule generation modifications, this would probably fix your problems. If you look at the -current list archives, you will see a number of posts which identify the files which have changed, and are probably what is breaking you [ comments on policy related to commits of kernel changes without corresponding commits to user space utilities elided ]. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c
On Mon, Apr 08, 2002 at 12:15:17PM +0200, Dag-Erling Smorgrav wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: On Sun, Apr 07, 2002 at 01:43:27PM -0700, Dag-Erling Smorgrav wrote: Log: Fix bug in previous commit that passed the wrong default value to login_getcapstr(3). Also fix a longer-standing bug (login_close(3) frees the string returned by login_getcapstr(3)) by reorganizing the code a little, and use login_getpwclass(3) instead of login_getclass(3) if we already have a struct pwd. This change also broke the Password: prompt. The bug is hidden by the -Wno-uninitialized setting in bsd.sys.mk. Here's the patch: The commit you quote *fixed* the bug you're referring to. You're right. I forgot to relink pam_ssh.so library, and the diff was against the wrong revision. I will still commit the const poisoning patch to libutil, as the impact turned out to be really low. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg37092/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c
Ruslan Ermilov [EMAIL PROTECTED] writes: You're right. I forgot to relink pam_ssh.so library, and the diff was against the wrong revision. I will still commit the const poisoning patch to libutil, as the impact turned out to be really low. Thanks, const poisoning is a Good Thing [tm]. BTW, could you try to figure out a way we can split up the libpam build so the modules can depend on libpam.so? What I'd like is: 1) build static modules 2) build static and dynamic libpam 3) build dynamic modules (with dependency on libpam.so) or 1) build dynamic libpam 2) build modules (with dependency on libpam.so) 3) build static libpam or something similar. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel debugging - what's the procedure?
On Mon, Apr 08, 2002 at 04:25:59AM -0700, Terry Lambert wrote: Yes, that's what I implied by the above paragraph. I was up-to-date with sources yesterday. This is probably your problem. If you can back up to when the problem first appeared, or back out the kernel dump fule generation modifications, this would probably fix your problems. If you look at the -current list archives, you will see a number of posts which identify the files which have changed, and are probably what is breaking you [ comments on policy related to commits of kernel changes without corresponding commits to user space utilities elided ]. Looking at todays commits it looks like the gdb/kernel coredump problem has been fixed, at bde's bequest. Joe msg37094/pgp0.pgp Description: PGP signature
Re: 5-CURRENT source upgrade path is broken in PAM
On Thu, Mar 07, 2002 at 05:16:52PM +, Mark Murray wrote: Mark Murray [EMAIL PROTECTED] writes: Umm, IIRC 'make world' starts by doing a 'make includes' into /usr/obj, which should take care of this. That is 'make world'. It was broken for make obj make depend make, [...] IMO, the repo-copy is the cleanest, because it solves te above problems in the most canonical way. Please talk to Ruslan about this. I suggested doing just what you're thinking of about a month or two ago, and he rejected it. Ruslan is not writing this code; we are. But Ruslan might have an idea because he has eaten a few dogs on make world issues. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg37095/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c
On Mon, Apr 08, 2002 at 02:49:04PM +0200, Dag-Erling Smorgrav wrote: Ruslan Ermilov [EMAIL PROTECTED] writes: You're right. I forgot to relink pam_ssh.so library, and the diff was against the wrong revision. I will still commit the const poisoning patch to libutil, as the impact turned out to be really low. Thanks, const poisoning is a Good Thing [tm]. BTW, could you try to figure out a way we can split up the libpam build so the modules can depend on libpam.so? What I'd like is: 1) build static modules 2) build static and dynamic libpam 3) build dynamic modules (with dependency on libpam.so) or 1) build dynamic libpam 2) build modules (with dependency on libpam.so) 3) build static libpam or something similar. That should be as simple as that: %%% Index: Makefile.inc === RCS file: /home/ncvs/src/lib/libpam/modules/Makefile.inc,v retrieving revision 1.10 diff -u -r1.10 Makefile.inc --- Makefile.inc6 Apr 2002 19:32:37 - 1.10 +++ Makefile.inc8 Apr 2002 14:03:39 - @@ -9,11 +9,7 @@ CFLAGS+= -I${.CURDIR}/../../libpam WARNS?=4 -# This is nasty. -# For the static case, libpam.a depends on the modules. -# For the dynamic case, the modules depend on libpam.so.N -# Punt for the time being until I can figure out how to do it. -#DPADD+= ${LIBPAM} -#LDADD+= -lpam +# Break `checkdpadd' deliberately. +LDADD+=-lpam .include ../Makefile.inc %%% For the static case (Mark probably means building of libpam.a here), libpam.a indeed depends on the modules, but in the make(1) sense of dependency, which we (sorry, _you_ Mark :-) handle nicely with the STATIC_MODULES thingie. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg37096/pgp0.pgp Description: PGP signature
Re: cvs commit: src/lib/libpam/modules/pam_unix pam_unix.c
Ruslan Ermilov [EMAIL PROTECTED] writes: That should be as simple as that: [...] Thank you very much! DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic sleeping without a mutex in usb_task_thread
On my laptop (but not the build machine; the latter may not have any USB devices) I get the following panic after builing, installing, trying to boot -CURRENT from today. (CVSup log below panic trace.) an0: Ethernet address 00:40:96:32:19:a9 bpf: an0 attached panic: sleeping without a mutex Debugger(panic) Stopped at Debugger+0x40: xorl%eax,%eax db trace Debugger(c03d647c) at Debugger+0x40 panic(c03d6cac,c021ffec,c8e4e000,c8e4e100,c8e4e000) at panic+0x70 msleep(c0442d98,0,5c,c03c7784,0) at msleep+0x23 usb_task_thread(0,c8e6ad48,c8e4e100,c021ffec,0) at usb_task_thread+0x23 fork_exit(c021ffec,0,c8e6ad48) at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x37 dbshow locks dbshow witness [scrolls off screen] db [Above was hand-transcribed; I don't have a serial console on my laptop, and I'm not running VMware.] Recent CVSup history: freebeast(4.5-S)[1] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Thu Apr 4 03:47:06 PST 2002 CVSup ended from cvsup14.freebsd.org at Thu Apr 4 03:53:56 PST 2002 CVSup begin from cvsup14.freebsd.org at Fri Apr 5 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Fri Apr 5 03:54:13 PST 2002 CVSup begin from cvsup14.freebsd.org at Sat Apr 6 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Sat Apr 6 03:54:32 PST 2002 CVSup begin from cvsup14.freebsd.org at Sun Apr 7 03:47:03 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sun Apr 7 03:53:32 PDT 2002 CVSup begin from cvsup14.freebsd.org at Mon Apr 8 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Mon Apr 8 03:53:43 PDT 2002 freebeast(4.5-S)[2] I can leave it in this condition for a while, if it would be helpful to poke around at all. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] Based on my experience as a computing professional, I consider the use of Microsoft products as components of computing systems to be just as advisable as using green wood to frame a house... and expect similar results. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Intel i830 driver?
Hi, all From: James Satterfield [EMAIL PROTECTED] Subject: Re: Intel i830 driver? Date: Fri, 5 Apr 2002 21:35:46 -0800 Message-ID: 01b601c1dd2c$e6ec2620$0feba8c0@sphynx james I have a Dell Latitude C400 with an Intel i830M graphics chip. Running james 4.5-stable, the i810 driver complains about not finding the (I assume AGP) james bridge device. Here's my dmesg. I am struggling the same issue too, and trying to support i830MG as /dev/agpgart on FreeBSD 4.5-STABLE. Unfortunately I have not succeeded but you can take a look at my patches at http://snowwind.kawasaki3.org/. # Please note that these patch is NOT completed. Thank you very much. moto kawasaki [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: patch: make syslog stop spamming any root it finds...
On Sat, Apr 06, 2002 at 08:39:51AM +0200, [EMAIL PROTECTED] wrote: I have always hated the three lines in /etc/syslog.conf which spams root with far too many and far too irrellevant syslog messages, in some cases even with several copies of them. Amen to that. You got my vote. Usually when I set up a FreeBSD box, it's the first thing I turn off. I say commit it. Likewise, it's the first thing I turn off, as well as the *.emerg line that broadcasts to all users. Same here. First things removed on a fresh FreeBSD install. Please commit. Not only the first thing I do with a new FreeBSD box, the first thing I did on FreeBSD: remove those 3 lines from syslog.conf that tell you how many people are poping their mail etc. // George -- GEORGE GEORGALIS, System Admin/Architectcell: 347-451-8229 Security Services, Web, Mail,mailto:[EMAIL PROTECTED] File, Print, DB and DNS Servers. http://www.galis.org/george To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: panic sleeping without a mutex in usb_task_thread
On 08-Apr-2002 David Wolfskill wrote: On my laptop (but not the build machine; the latter may not have any USB devices) I get the following panic after builing, installing, trying to boot -CURRENT from today. (CVSup log below panic trace.) an0: Ethernet address 00:40:96:32:19:a9 bpf: an0 attached panic: sleeping without a mutex Debugger(panic) Stopped atDebugger+0x40: xorl%eax,%eax db trace Debugger(c03d647c) at Debugger+0x40 panic(c03d6cac,c021ffec,c8e4e000,c8e4e100,c8e4e000) at panic+0x70 msleep(c0442d98,0,5c,c03c7784,0) at msleep+0x23 usb_task_thread(0,c8e6ad48,c8e4e100,c021ffec,0) at usb_task_thread+0x23 fork_exit(c021ffec,0,c8e6ad48) at fork_exit+0x8c fork_trampoline() at fork_trampoline+0x37 dbshow locks dbshow witness [scrolls off screen] db [Above was hand-transcribed; I don't have a serial console on my laptop, and I'm not running VMware.] Recent CVSup history: freebeast(4.5-S)[1] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Thu Apr 4 03:47:06 PST 2002 CVSup ended from cvsup14.freebsd.org at Thu Apr 4 03:53:56 PST 2002 CVSup begin from cvsup14.freebsd.org at Fri Apr 5 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Fri Apr 5 03:54:13 PST 2002 CVSup begin from cvsup14.freebsd.org at Sat Apr 6 03:47:02 PST 2002 CVSup ended from cvsup14.freebsd.org at Sat Apr 6 03:54:32 PST 2002 CVSup begin from cvsup14.freebsd.org at Sun Apr 7 03:47:03 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sun Apr 7 03:53:32 PDT 2002 CVSup begin from cvsup14.freebsd.org at Mon Apr 8 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Mon Apr 8 03:53:43 PDT 2002 freebeast(4.5-S)[2] I can leave it in this condition for a while, if it would be helpful to poke around at all. show witness isn't useful to most people so I would avoid it unless someone explicitly asks for it. The problem here is likely due to the usb_task_thread() not locking Giant when it starts up. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic sleeping without a mutex in usb_task_thread
On Mon, Apr 08, 2002 at 12:33:40PM -0400, John Baldwin wrote: show witness isn't useful to most people so I would avoid it unless someone explicitly asks for it. The problem here is likely due to the usb_task_thread() not locking Giant when it starts up. We probably want this: Index: usb.c === RCS file: /home/ncvs/src/sys/dev/usb/usb.c,v retrieving revision 1.75 diff -u -5 -r1.75 usb.c --- usb.c 7 Apr 2002 14:21:32 - 1.75 +++ usb.c 8 Apr 2002 17:58:38 - -423,10 +423,14 usb_task_thread(void *arg) { struct usb_task *task; int s; +#ifdef __FreeBSD__ + mtx_lock(Giant); +#endif + DPRINTF((usb_task_thread: start\n)); s = splusb(); for (;;) { task = TAILQ_FIRST(usb_all_tasks); Joe msg37102/pgp0.pgp Description: PGP signature
Re: panic sleeping without a mutex in usb_task_thread
On 08-Apr-2002 Josef Karthauser wrote: On Mon, Apr 08, 2002 at 12:33:40PM -0400, John Baldwin wrote: show witness isn't useful to most people so I would avoid it unless someone explicitly asks for it. The problem here is likely due to the usb_task_thread() not locking Giant when it starts up. We probably want this: Probably unless some USB specific locks are added instead, but this is the easier fix for the time being. Index: usb.c === RCS file: /home/ncvs/src/sys/dev/usb/usb.c,v retrieving revision 1.75 diff -u -5 -r1.75 usb.c --- usb.c 7 Apr 2002 14:21:32 - 1.75 +++ usb.c 8 Apr 2002 17:58:38 - @@ -423,10 +423,14 @@ usb_task_thread(void *arg) { struct usb_task *task; int s; +#ifdef __FreeBSD__ + mtx_lock(Giant); +#endif + DPRINTF((usb_task_thread: start\n)); s = splusb(); for (;;) { task = TAILQ_FIRST(usb_all_tasks); Joe -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic sleeping without a mutex in usb_task_thread
On Mon, Apr 08, 2002 at 01:37:55PM -0400, John Baldwin wrote: On 08-Apr-2002 Josef Karthauser wrote: On Mon, Apr 08, 2002 at 12:33:40PM -0400, John Baldwin wrote: show witness isn't useful to most people so I would avoid it unless someone explicitly asks for it. The problem here is likely due to the usb_task_thread() not locking Giant when it starts up. We probably want this: Probably unless some USB specific locks are added instead, but this is the easier fix for the time being. Cool. I've committed this; where should I look to get a low down on what to lock, when and how? Is there anything other than source to refer to? Joe msg37104/pgp0.pgp Description: PGP signature
Re: ld-elf.so.1 broken with world from yesterday
On Mon, Apr 08, 2002 at 11:07:21AM +0100, Alexander Leidinger wrote: yesterday I've made a new world. After booting it, ld-elf-so.1 complains about every library (libc, libutil, ...). My -current is not usable anymore because of this. Defined complains. freebsd-current readers should know to spend EXACT error messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic sleeping without a mutex in usb_task_thread
On 08-Apr-2002 Josef Karthauser wrote: On Mon, Apr 08, 2002 at 01:37:55PM -0400, John Baldwin wrote: On 08-Apr-2002 Josef Karthauser wrote: On Mon, Apr 08, 2002 at 12:33:40PM -0400, John Baldwin wrote: show witness isn't useful to most people so I would avoid it unless someone explicitly asks for it. The problem here is likely due to the usb_task_thread() not locking Giant when it starts up. We probably want this: Probably unless some USB specific locks are added instead, but this is the easier fix for the time being. Cool. I've committed this; where should I look to get a low down on what to lock, when and how? Is there anything other than source to refer to? Nothing besides the source really. If it's walking a list you might use a lock to protect the list for example, but then you might need to conditionally get Giant while performing an action on the list. Joe -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Fatal double fault on -current
Hackers, for the last couple of days i was able to crash my -current laptop with Fatal double fault panic whenever i wanted. i have created a small spherical cow :) to demonstrate the problem (see attached). this is pretty much what my code does. just compile and load the cow and then try # ngctl msg cow: moo i'm suspecting m_split() and have attached tiny path that fixes problem for me. of course it might be just my fault :) and i'm missing some small thing. ... if you think you found the bug - you don't... thanks, max /* * ng_cow.c * * Copyright (c) 2001-2002 Maksim Yevmenkin [EMAIL PROTECTED] * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright *notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright *notice, this list of conditions and the following disclaimer in the *documentation and/or other materials provided with the distribution. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. */ #include sys/param.h #include sys/systm.h #include sys/errno.h #include sys/kernel.h #include sys/malloc.h #include sys/mbuf.h #include netgraph/ng_message.h #include netgraph/netgraph.h #include netgraph/ng_parse.h #define NG_COW_NODE_TYPEcow #define NGM_COW_COOKIE 1018303300 #define NGM_COW_MOO 1 /* MALLOC define */ #ifdef NG_SEPARATE_MALLOC MALLOC_DEFINE(M_NETGRAPH_COW, cow, Netgraph spherical cow); #else #define M_NETGRAPH_COW M_NETGRAPH #endif /* NG_SEPARATE_MALLOC */ /* Netgraph node methods */ static ng_constructor_t ng_cow_constructor; static ng_rcvmsg_t ng_cow_rcvmsg; static ng_shutdown_tng_cow_shutdown; static ng_newhook_t ng_cow_newhook; static ng_connect_t ng_cow_connect; static ng_rcvdata_t ng_cow_rcvdata; static ng_disconnect_t ng_cow_disconnect; static int ng_cow_modevent __P((module_t, int, void *)); /* Netgraph node command list */ static const struct ng_cmdlist ng_cow_cmdlist[] = { { NGM_COW_COOKIE, NGM_COW_MOO, moo, NULL, NULL }, { 0, } }; /* Netgraph type descriptor */ static struct ng_type typestruct = { NG_ABI_VERSION, NG_COW_NODE_TYPE, /* typename */ ng_cow_modevent,/* modevent */ ng_cow_constructor, /* constructor */ ng_cow_rcvmsg, /* control message */ ng_cow_shutdown,/* destructor */ ng_cow_newhook, /* new hook */ NULL, /* find hook */ ng_cow_connect, /* connect hook */ ng_cow_rcvdata, /* data */ ng_cow_disconnect, /* disconnect hook */ ng_cow_cmdlist /* node command list */ }; NETGRAPH_INIT(cow, typestruct); MODULE_VERSION(ng_cow, 1); static int ng_cow_moo __P((void)); static struct mbuf *ng_cow_prepend __P((struct mbuf *, int)); /* * **Netgraph node interface * */ static node_p the_node = NULL; /* * Handle loading and unloading for this node type */ static int ng_cow_modevent(mod, event, data) module_t mod; int event; void*data; { int error = 0; switch (event) { case MOD_LOAD: error = ng_make_node_common(typestruct, the_node); if (error != 0) break; error = ng_name_node(the_node, NG_COW_NODE_TYPE); if (error != 0) { NG_NODE_UNREF(the_node); the_node = NULL; break; } break; case MOD_UNLOAD: error = EBUSY; break;
fwiw: nfs loopback still broken in -current
NFS loopback mounts still periodically gets hung with: ypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I/usr/include -D_KERNEL -ffreestanding -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev56 vers.c linking kernel.debug nfs server yorp:/space/compiles: not responding 10 9 . This has been the case for months and months. -matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
LOOKUP_SHARED is default now
This patch has seriously reduced file system deadlocks for several people. It also makes concurrent file system access much faster in certain cases. Since I have only heard good reports and no bad reports I'm going to enable it by default. If you do experience some file system deadlocks please let me know. You may revert to the previous behavior with 'options LOOKUP_EXCLUSIVE'. I will take this away after a month or so if there are no problems. Thanks, Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
boot failure
After a buildworld / buildkernel /installkernel / installworld on my current system from yesterday sources (about 19:00 CET) my system doesnt boot: The kernel and the acpi module will be loaded and then nothing happens for a second, something is accessing the hd and i get a login screen. No hardware detect and nothing else before the login only kernel and acpi loaded. Of course you cant login... you cant input anything :) Jan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message