Re: Interest in nvidia-driver debugging on 5-*
On 13 Jun 2003, Samy Al Bahra wrote: Hey, I believe the fix is as simple as saving and restoring %gs in the nVidia driver, and/or not letting the nVidia use %gs at all (segment registers generally belong to the OS, in any case, and stealing a CPU register of any kind for exclusive use of a driver is a pig trick). Please take a look at http://www.minion.de/ Christian Zander has written a patch to deal with the gs restoration problem and other issues. It is well tested and adopted. Maxime Henrion has also written several patches which may be found in the ports system (x11/nvidia-driver). I think Terry is jumping to conclusions on what Evan's problem could be. I have this seen this cause application to crash at exit (if using OpenGL) but never a crash in kernel-space from the nVidia drivers. No, I don't think Terry is jumping to conclusion. Read the archives of this problem. The Nvidia drivers and OpenGL for FreeBSD won't work with -current and any threading library other than libc_r. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
Samy Al Bahra wrote: I think Terry is jumping to conclusions on what Evan's problem could be. I have this seen this cause application to crash at exit (if using OpenGL) but never a crash in kernel-space from the nVidia drivers. 1) It works with libc_r, but not with libthr and not with libkse. 2) The %gs register is not used by libc_r, but is used for threads context for the other two. 3) Most of the other code is shared between the libraries. Draw your own conclusions... 8-). Also read the recent post about nVidia to the threads list about %gs. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: adsl/pppoe no longer connecting on 5.1
David O'Brien [EMAIL PROTECTED] writes: Acutally -std=c?9, -std=gnu?9 uses GCC's alloca. I don't mind finding all the alloca uses in the tree and compiling them with -std=gnu99 instead of -std=c99. #define alloca(sz) __builtin_alloca(sz) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PR/53008
Hi Peter, would you please be so kind and have a look at PR/53008 (http://www.freebsd.org/cgi/query-pr.cgi?pr=53008), because you committed src/sys/i386/acpica/genwakecode.sh and under some circumstances an errornously output is generated (details in PR). The problem hits me when I was updating a plain installed machine (5.1-BETA) to 5-CURRENT one day before release mounting the sources via nfs. Because of a problem with the new pci code I had to switch back to an old kernel but the new world was already active (I know, not installed like recommented in handbook). Jens ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
Daniel Eischen Wrote: No, I don't think Terry is jumping to conclusion. Read the archives of this problem. The Nvidia drivers and OpenGL for FreeBSD won't work with -current and any threading library other than libc_r. I didn't deal with any users having kernel crashes from this %gs restoration bug only OpenGL-linked applications crashing at exit (such as QT applications, do look at minion.de for a better description). You're incorrect in many premises here (as Terry kindly pointed out). Terry Lambert Wrote: Draw your own conclusions... 8-). Also read the recent post about nVidia to the threads list about %gs. It's kind of hard with no debugging information :) Will look at that thread though. -- +---+ | Samy Al Bahra | [EMAIL PROTECTED] | +---+ Arabeyes.org Kerneled.com FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CSTD=c99 breaks package creation
On Thu, Jun 12, 2003, Tim Robbins wrote: On Wed, Jun 11, 2003 at 07:37:01PM -0700, Kris Kennaway wrote: It's possible that there's either a bug in gcc or there is C code in the system that has a different meaning when interpreted to C99 standards. I think I may have found the problem, and I think it's in GNU tar. GNU tar does this: #ifndef __attribute__ /* This feature is available in gcc versions 2.5 and later. */ # if __GNUC__ 2 || (__GNUC__ == 2 __GNUC_MINOR__ 5) || __STRICT_ANSI__ # define __attribute__(Spec) /* empty */ # endif #endif machine/_types.h does this: typedef int __attribute__((__mode__(__DI__))) __int64_t; typedef unsigned int __attribute__((__mode__(__DI__))) __uint64_t; If __attribute__ is empty, __int64_t becomes a synonym for int. Bad. Wow! Nice catch... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-current Digest, Vol 12, Issue 13
Please use our new ticket-based support system. Doing so will allow us to handle your request more efficiently and quickly. http://www.wasabihosting.com/helpdesk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
Samy Al Bahra wrote: Daniel Eischen Wrote: No, I don't think Terry is jumping to conclusion. Read the archives of this problem. The Nvidia drivers and OpenGL for FreeBSD won't work with -current and any threading library other than libc_r. I didn't deal with any users having kernel crashes from this %gs restoration bug only OpenGL-linked applications crashing at exit (such as QT applications, do look at minion.de for a better description). You're incorrect in many premises here (as Terry kindly pointed out). Uh, Daniel and I are in total agreement on this one; I don't know what I'm supposed to have pointed out, but I was basically going off a conversation between Daniel and an nVidia user, and my understanding of the threads library code in the three libraries. BTW: a corrupted %gs can crash a user space program that's threaded and expects a different value, without actually crashing the kernel: it all depends on who trashes who's %gs first, since if you crash in user space from a %gs set by the kernel to an unexpected value, then you aren't going to get the opportunity to set it to a value that will crash the kernel becase, well, having crashed, you aren't runnung any more to execute the code to do it. 8-). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fxp0: device timeout with 5.1BETA2
UPDATE: If I make an SMP-kernel this issue is completely solved for me. Everythings works as before, both fxp's share the same irq (together with uhci), both are working, with sio, usb, etc ... like as before the evil cvsup :-) Markus On Wed, Jun 11, 2003 at 10:34:15AM +0200, Markus Wennrich wrote: On Tue, Jun 10, 2003 at 02:08:54PM +0200, Markus Wennrich wrote: fxp0: device timeout I get these as well. Is it on irq9 by any chance, along with acpi0 ? No. It's on irc 11 device 8 (as dmesg states). All irqs in bios are set to 11 (factory default). ACPI is disabled. Ok, well that's a useful data point (for me anyway) since it means there's a problem with fxp losing interrupts that's not related to some other ACPI problems I've experienced, suggesting that it's therefore a fxp driver problem. I have the same problem here with a freshly cvsupped 5.1-CURRENT. The machine has two fxp-NICs and I get device timeouts with both of them (with acpi enabled or disabled, both the same, no change). See attached dmesg. Well, I got a little further: Until yesterday, my fxp's both hat irq 10, shared with the uhci-usb-controller. Everything worked fine. Since the cvsup, fxp0 uses irq 3 (shared with sio0) and fxp1 irq 10 (shared with uhci0), which didn't work. If I remove sio from my kernel-config, fxp0 works fine. But if I use the fxp1-device (dhclient or ifconfig) the machine freezes immediatly. Then I tried to also remove the usb-support, so the fxp1 has irq 10 soley for itself ... doesn't work. The machine still freezes. (I tried to pinpoint both irq's to irq 3 via device.hints (hint.fxp.1.irq=3) ... didn't worked.) Well ... at least I can use fxp0 if it has its irq soley for itself. But the machine still freezes, if I try to use fxp1. Any ideas what else I could try? I volunteer for debugging ;-) Bye, Markus -- Unix IS user friendly ... it's just selective about who its friends are. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] -- Gibt es irgendwelche Regeln? - Ja. Wer zuerst stirbt, verliert. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Interest in nvidia-driver debugging on 5-*
hello, Any chance someone can support nforce2's chipset agp? Not all of us own nvidia graphics cards :-( I don't know how hard it is to get this working on freebsd. here's some code: http://groups.google.com/groups?hl=enlr=ie=UTF-8oe=utf-8threadm=20030524205432.GA17179%40suse.de.lucky.linux.kernelrnum=18prev=/groups%3Fq%3Dnvidia%2Bagp%2Bnforce2%2Blinux%26num%3D100%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26sa%3DN%26scoring%3Dd -- Bruno Miguel Afonso Biological Eng. student. D.E.Q. @ I.S.T. - Portugal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Support DHCP in rc.firewall by default?
Right now, rc.firewall isn't set up to support DHCP configurations although it could easily be done so. Googling comes up with many references, for example http://www.freebsddiary.org/firewall.php (section ipfw with DHCP etc at the bottom of the page). Are there any reasons against having rc.firewall contain such lines? I reckon it would even come in handy for statically configured users: they'd only need to specify their network interface(s) once. Roderick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: ALTQ for FreeBSD 5.1?
Erik Paulsen Skaalerud ([EMAIL PROTECTED]) wrote: Is anyone working on ALTQ intergration for FreeBSD 5.1? [...] I recently took interest in this (about a month ago) and had ALTQ port updated to work with the latest 5.0. The only issue I have had was with fxp and TBR magic; once I find an fxp(4) guru, I will get that sorted. If you're looking for a fxp hacker, mux is the one you want ([EMAIL PROTECTED]). He's also on irc.freenode.net with the same nickname. Isn't someone working on integrating ALTQ and pf - similar to what has been done for OpenBSD? Regards, Holger ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ for FreeBSD 5.1?
Holger Kipp wrote: If you're looking for a fxp hacker, mux is the one you want ([EMAIL PROTECTED]). He's also on irc.freenode.net with the same nickname. Isn't someone working on integrating ALTQ and pf - similar to what has been done for OpenBSD? here you go: http://pf4freebsd.love2party.net/index.html I'd love freebsd to have altq and pf or ipf integration on base system.. -- Bruno Miguel Afonso Biological Eng. student. D.E.Q. @ I.S.T. - Portugal ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ for FreeBSD 5.1?
Bruno Afonso wrote: Holger Kipp wrote: Isn't someone working on integrating ALTQ and pf - similar to what has been done for OpenBSD? here you go: http://pf4freebsd.love2party.net/index.html I'd love freebsd to have altq and pf or ipf integration on base system.. If it can be one as a kernel module, that's the way to do it, instead of integrating it. Alt-Q is experimental code, and, as such, there is academic disagreement on whether it'd be a good idea to integrate it in such a way as it could not be removed. Integrating pf that way would just break the ability to use competing code, for political reasons that not all of us would agree with. So if the code's integratedat all, it should be done as modules. FWIW: Alt-Q does nothing about impedence mismatches; for example, if I have a fast local pipe on a machine acting as a gateway to a slow connection to a much fater network (think NAT box on a DMZ border hooked to a DSL or cable modem), then no matter what I do with Alt-Q, I'm screwed at the network service providers end by the buffer limitations and queueing policy between their OC3 (or whatever) and their DSLM/cable fan out unit. This is because bandwidth usage is asymmetric: if I have two sets of traffic, the NSP's router will fill its buffers alloted to me with one type of traffic/one connections traffic. After that, I can Alt-Q until I'm blue in the face on my end, but without me draining out the NSP's router's packet buffer, no new packets of the right type will gets through. The only way it works is if the NSP is also running Alt-Q, and you have prereserved high water marks for traffic bands, so that even if 90% of your allotted buffers get filled up, there's still 10% reservation for ssh for you to get into and talk to your machine. I much prefer Julian Elischer's approach to solving this problem, which doesn't require cooperation from the NSP. So this recent hard push for Alt-Q in the base system as anything other than a module is a really, really bad idea, in the opinions of some of us. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ALTQ for FreeBSD 5.1?
On Fri, Jun 13, 2003 at 09:39:37AM +, Holger Kipp wrote: Erik Paulsen Skaalerud ([EMAIL PROTECTED]) wrote: Is anyone working on ALTQ intergration for FreeBSD 5.1? [...] I recently took interest in this (about a month ago) and had ALTQ port updated to work with the latest 5.0. The only issue I have had was with fxp and TBR magic; once I find an fxp(4) guru, I will get that sorted. If you're looking for a fxp hacker, mux is the one you want ([EMAIL PROTECTED]). He's also on irc.freenode.net with the same nickname. Isn't someone working on integrating ALTQ and pf - similar to what has been done for OpenBSD? Yes, but even if the PF is ported, you still need to download the ALTQ package fromt he ROFUG.org site, because the KAME implementation is used. Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Duplicate keys in CVSROOT/modules
David O'Brien (obrien) writes: Any committer can fix this -- just check out modules and add port_ in front of the ports one. Ah ! It has been fixed now. /mich -- Best Regards, Michael L. Hostbaek FreeBSD Committer - FreeBSD: The power to serve [EMAIL PROTECTED] - http://www.FreeBSD.org */ PGP-key available upon request /* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: kmem_malloc(4096): kmem_map too small
Hi, On a 5.1-RELEASE machine I have been able to cause a panic like this: panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated The machine is an old 300MHz Celeron with 64M Ram. I get the panic by un-taring a huge .tgz file onto a vinum partition which is on a scsi disk behind a Adaptec 2940 controller. The huge tar file contains a normal user 5.1 installation plus the 5.1-RELEASE bits from the ftp site, so it is a 320 Meg .tgz. I have played around a bit. It seems to panic a little quicker if the machine have only 32M Ram. I haven't been able to panic it if I do it in a normal, non-vinum partition. I don't know if vinum is at fault though, it might just help to agravate the situation. Here follow the output of vinum list and then the panic message and a gdb traceback. I'm not sure if the traceback is correct. I think it only show the second panic. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] The output of vinum list: ### 1 drives: D vd0 State: up /dev/da0s1d A: 0/966 MB (0%) 1 volumes: V root State: up Plexes: 1 Size:966 MB 1 plexes: P root.p0 C State: up Subdisks: 1 Size:966 MB 1 subdisks: S root.p0.s0State: up D: vd0 Size:966 MB ### GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: free locked buf panic messages: --- panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated syncing disks, buffers remaining... panic: free locked buf Uptime: 1h47m5s (da0:ahc0:0:6:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da0:ahc0:0:6:0): error code 54 Dumping 64 MB ata0: resetting devices .. done 16 32 48 --- Reading symbols from /usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug #0 doadump () at ../../../kern/kern_shutdown.c:238 238 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:238 #1 0xc01ab1ca in boot (howto=260) at ../../../kern/kern_shutdown.c:370 #2 0xc01ab483 in panic () at ../../../kern/kern_shutdown.c:543 #3 0xc1064926 in freerq (rq=0xc166c4c0) at /usr/src/sys/dev/vinum/vinuminterrupt.c:252 #4 0xc106482a in complete_rqe (bp=0xc12a6c24) at /usr/src/sys/dev/vinum/vinuminterrupt.c:230 #5 0xc01eda81 in bufdone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:3086 #6 0xc01ed984 in bufdonebio (bp=0x0) at ../../../kern/vfs_bio.c:3034 #7 0xc01ed7e2 in biodone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:2961 #8 0xc017d4be in g_dev_done (bp2=0xc1552120) at ../../../geom/geom_dev.c:391 #9 0xc01ed7e2 in biodone (bp=0xc1552120) at ../../../kern/vfs_bio.c:2961 #10 0xc017fc62 in g_io_schedule_up (tp=0xc0607e40) at ../../../geom/geom_io.c:365 #11 0xc017fe58 in g_up_procbody () at ../../../geom/geom_kern.c:91 #12 0xc01986ce in fork_exit (callout=0xc017fe30 g_up_procbody, arg=0x0, frame=0x0) at ../../../kern/kern_fork.c:768 (kgdb) quit ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Support DHCP in rc.firewall by default?
From: Roderick van Domburg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Date: Fri, 13 Jun 2003 11:18:45 +0200 Subject: Support DHCP in rc.firewall by default? Right now, rc.firewall isn't set up to support DHCP configurations although it could easily be done so. More or less, depending on one's requirements. Googling comes up with many references, for example http://www.freebsddiary.org/firewall.php (section ipfw with DHCP etc at the bottom of the page). Are there any reasons against having rc.firewall contain such lines? I reckon it would even come in handy for statically configured users: they'd only need to specify their network interface(s) once. Well, you might consider submitting a PR with a suggested patch. :-) That said: a while back (around the time that the BayLISA meetings moved to Apple's facility, where they have wireless Internet access available, and the DHCP server provides routable IP addresses), I decided that setting up my laptop to make use of ipfw would be A Good Thing. The approach I used was to have a default configuration that blocked everything but DHCP/BOOTP, then, in /etc/dhclient-exit-hooks, once I know I have received a DHCP lease, invoke a script (with the newly-assigned IP address as one of the arguments). Note that I also had set up dhclient-exit-hooks to determine my hostname (given the IP address) -- if it could, and to try to make use of an NTP server. Whether or not all of that comes very close to anyone else's perceived requirements, I don't know -- but my guess is that it is fairly idiosyncratic, at best. Peace, david -- David H. Wolfskill [EMAIL PROTECTED] Based on what I have seen to date, the use of Microsoft products is not consistent with reliability. I recommend FreeBSD for reliable systems. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
rpc.yppasswdd failed in FreeBSD 5.1
hello, I setup a NIS Master in FreeBSD 5.1 release, and it works. I also startup rpc.yppasswdd. When I wnat to change a user's passwd using yppasswd, it failed. root# passwd testuser Changing NIS password for testuser Old Password: New Password: Retype New Password: passwd: pam_chauthtok(): error in service module Jun 13 22:22:24 abcb passwd: in pam_sm_chauthtok(): yppasswd_local(): failed to connect to rpc.yppasswdd: .xxx.xxx.xxx: RPC: Program not registered I had set hosts.allow for rpcbind and ypserv to allow accessing. please help me to solve this. thank you. Tsung Ching Lin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Bulding libc.so with gnu99 is dangerous!
After installing libc.so builded with standard bsd.sys.mk (i.e. with gnu99) all shared programs reports missing 'SYS_sigreturn' name and fails to start. When I restore old libc and rebuild libc without gnu99, all works fine again. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Compaq Presario 2140US w/Current - no mouse/pointpad?!
Hi folks; I've got an odd one here... Trying to run 5.1-RELEASE on a Presario 2140-US laptop (4.x locks up in an odd way on boot, and I can't get into the user config - that goes into an infinite keyboard read loop at boot when you use the -c option?!) Anyway, the -c option appears to have been removed from the kernel boot on 5.x (so I can't look for possible conflicts before startup), and the mouse doesn't initialize. Booting verbose says that the IRQ cannot be allocated (irq 12), but a careful persusal of the boot log shows no other devices attempting to attach to, or actually attached to, that interrupt. Any ideas? I'd like to get the X-server and KDE running on this thing, and shed the borg (XP) if I can I'm not new at FreeBSD in any way, but things appear to have changed significantly in the user config area with 5.x, and I've run out of self-help ideas on this one... Other than the mouse (touchpad) not initializing with this error, and some niggling ACPI issues (apparently the Compaq has some ACPI capabilities that 5.x doesn't, and there is some kind of clash causing error messages once in a while during state changes such as from battery to AC) everything ELSE appears to work properly. -- -- Karl Denninger ([EMAIL PROTECTED]) Internet Consultant Kids Rights Activist http://www.denninger.netTired of spam at your company? LOOK HERE! http://childrens-justice.orgWorking for family and children's rights http://diversunion.org LOG IN AND GET YOUR TANK STICKERS TODAY! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Belkin USB 2.0 Cardbus card
Has anyone got one of these cards working? I plug it into my laptop with 5.1, cvsupped on Monday or Tuesday (long week), and try to plug this card in. It is recognized the card, but has errors and disables them. I also am trying a Sony DRX-500UL drive. It's recognized in the built-in USB 1.1 ports, and I'm able to mount a CD. Any chance burning on it could happen? CD VCD and DVD +/- RW. Thanks, Paul. -- Paul T. RootCCSA, CCSE, CCNA Qwest CommunicationsPAG: +1 (877) 693-7155 600 Stinson Blvd, Flr 1SWRK: +1 (612) 664-3385 Minneapolis, MN 55413 FAX: +1 (612) 664-4778 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: kmem_map too small: the downside of FreeBSD 5
John Hay wrote: On a 5.1-RELEASE machine I have been able to cause a panic like this: panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated Manually tune your system. This panic results from the fact that zone allocations with fixed limits don't really do the right thing any more, now that it's possible to implement the map entry allocations at interrupt. Before the new memory allocator, there was an allocator entry point called zalloci() that differed from zalloc() in that it pre-allocated its map entries at declaration time, so that there was always backing in KVA for yet-to-be-allocated pages. With the new memory allocator, this is no longer the case. Because of this, the kmem_map must be extended when the amount of memory request would require a KVA mapping that does not yet exist. Normally this is only a problem if you have a huge amount of memory, and there's not enough KVA to create the page mappings. This can happen on auto-tuned systems using PAE, PSE36, or a similar method, with more than 3-4G of physical RAM, since the KVA is still limited to 4G - UVA size on these systems. It can also happen on any system that runs out of physical memory before filling in all the page mappings that would have been statically mapped with zalloci(), but aren't with plain zalloc() because of the new memory allocator. Really, as part of the switch to the new memory allocator, and the deprecation of the zalloci() interface that accompanied it, an audit should have been done of the system to go through all previous places zalloci() was used, and make them robust in case of a NULL return value (allocation failure), since those places were effectively promised by zalloci() that allocations would never fail for this reason. The panic call in the attempt to grow the kmem_map should probably be eliminated, to expose the places which are in error. The real problem here is that when you take a trap fault on a page-not-present, you can't return to the program that initiated the fault and cause it to block waiting for memory (for interrupts, this is just not possible). About the only code that used to allocate at interrupt that's robust in the face of the new memory allocator and kmem_map pressure is the mbuf code, since it has historically been prepared for a NULL return on an allocation request, and the intervening trap fault on the reserved KVA page for the page mapping doesn't bother it. IMO, the new memory allocator code needs to be refactored, in addition to an audit, as does the auto-tuning. Specifically, kernel memory is, with rare exceptions like the uarea, which people who don't understand are trying to kill off, non-pageable. A strategy that suggests itself is to provide page mappings for all of physical memory, before doing anything else. What memory remains is then available for use by the kernel. This would need a free-pool on top of everything else, since having a KVA mapping and owning a corresponding physical mapping would be two different things. Right now, your only option is to disable auto-tuning (set the value of maxusers to something other than 0), and manually tune the system, such that the total amount of prereserved and not-prereserved-but-allocable kernel memory can't exceed the physical memory size. You will have to take kernel size and kernel modules into account, if you want to get close to full utiilization of physical memory, if you do this. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-06-13 16:00:14 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-06-13 16:00:14 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-13 16:02:10 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-13 16:59:32 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Jun 13 16:59:32 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules/en. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-06-13 17:06:52 - /usr/bin/make returned exit code 1 TB --- 2003-06-13 17:06:52 - ERROR: failed to build generic kernel TB --- 2003-06-13 17:06:52 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Belkin USB 2.0 Cardbus card
* Paul T. Root ([EMAIL PROTECTED]) wrote: Has anyone got one of these cards working? I plug it into my laptop with 5.1, cvsupped on Monday or Tuesday (long week), and try to plug this card in. It is recognized the card, but has errors and disables them. A fix for this was posted to the list and added to -CURRENT sometime yesterday. I've no idea if there are any plans for a MFC as it only involved adding 2 lines to 2 files. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/ehci_pci.c.diff?r1=1.1r2=1.2 and http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/usb/uhci_pci.c.diff?r1=1.46r2=1.47 will get you the diffs that you need if you don't want to jump up to -CURRENT. HTH Alistair -- LJ : http://www.livejournal.com/users/everlone GPG/PGP: 6FA19F58 (http://wwwkeys.pgp.net) NP: pgp0.pgp Description: PGP signature
[-CURRENT tinderbox] failure on i386/i386
TB --- 2003-06-13 17:10:08 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-06-13 17:10:08 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-13 17:11:54 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-13 18:04:31 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Jun 13 18:04:32 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules/en. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-06-13 18:12:19 - /usr/bin/make returned exit code 1 TB --- 2003-06-13 18:12:19 - ERROR: failed to build generic kernel TB --- 2003-06-13 18:12:19 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_map too small: the downside of FreeBSD 5
On Fri, 13 Jun 2003, Terry Lambert wrote: John Hay wrote: On a 5.1-RELEASE machine I have been able to cause a panic like this: panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated Manually tune your system. This panic results from the fact that zone allocations with fixed limits don't really do the right thing any more, now that it's possible to implement the map entry allocations at interrupt. This is FUD. the deprecation of the zalloci() interface that accompanied it, an audit should have been done of the system to go through all previous places zalloci() was used, and make them robust in case of a NULL return value (allocation failure), since those places were effectively promised by zalloci() that allocations would never fail for this reason. They would fail before. This is FUD. More FUD was deleted. 5.0 simply consumes more memory than 4.x. Unfortunately even with kernel memory taking up 1/3rd of your resources we are not able to satisfy all requests. Some tuning of various memory consumers would be required to get this back down. I think this is a worthwhile effort as we should be able to run on a 32mb system still. Please note that I'm about to get on a plane and I will probably not reply to this message. Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: freebsd-current Digest, Vol 12, Issue 14
Please use our new ticket-based support system. Doing so will allow us to handle your request more efficiently and quickly. http://www.wasabihosting.com/helpdesk ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on i386/pc98
TB --- 2003-06-13 18:12:27 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-06-13 18:12:27 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-13 18:15:11 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-13 19:07:47 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Jun 13 19:07:47 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules/en. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src. TB --- 2003-06-13 19:14:16 - /usr/bin/make returned exit code 1 TB --- 2003-06-13 19:14:16 - ERROR: failed to build generic kernel TB --- 2003-06-13 19:14:16 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
In message [EMAIL PROTECTED], Craig Boston [EMAIL PROTECTED] wrote On Thu, 2003-06-12 at 08:14, Anthony Naggs wrote: Sorry, I don't understand this comment. All OHCI, UHCI EHCI USB controllers need PCI bus mastering in order to read update their various lists of pending completed transfers. That was speculation on my part as to why bus mastering was not being explicitly activated (i.e. maybe somebody had problems with it). It may just be that the BIOS always turns it on for the PCI version so there was never a need to. It seems likely it was never needed. Should we do this on uhci as well? Does anyone know if a such as thing as a cardbus uhci controller even exists? Yes, I think you should also do this for Uhci. There are probably not many straight Uhci USB 1.1 Cardbus cards, but it is likely some of the USB 2.0 cards have an UHCI controller rather than OHCI for USB 1.x support. Cheers, Tony ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMP in 5.1 cant deactivate hyperthreading
On Thu, 12 Jun 2003, Killing wrote: Halting them will still cause the CPUs to be detected. They just won't do any useful work. Yep but the issue is that all the core admin tools are unaware of this and hence include the virtual cores in idle calcs etc making load monitoring impossible without nasty cludges :( So what's the way forward? 1. Dont just use halt have a compile or other directive to disable them? 2. Update all tools to be halt aware? Personally I'd go with 2 all be it more work / ramifications on other 3rd party tools as it gives the benefit of also working when physical CPU's are halted. Guh. Checking with some people here, it appears that the HT stuff is still undergoing some tweaking. I'd suggest that you stay tuned for any commits from john baldwin re: HT. Your case appears to be unique. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build flags for a 386DX (5.1)
On Thu, 12 Jun 2003, John Nielsen wrote: [escalated from -questions] Hi folks- I am setting up FreeBSD 5.1-RELEASE on a 386DX. That works? 386 is not a supported CPU on 5.X. It is missing atomic operations that is necesary for proper operation of threading. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bulding libc.so with gnu99 is dangerous!
On Fri, Jun 13, 2003 at 07:40:53PM +0400, Andrey Chernov wrote: After installing libc.so builded with standard bsd.sys.mk (i.e. with gnu99) all shared programs reports missing 'SYS_sigreturn' name and fails to start. When I restore old libc and rebuild libc without gnu99, all works fine again. Please provide sufficent detail that I can track down your problem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildworld failing in /usr/src/gnu/usr.bin/binutils/libbfd
Hello list, I'm sure I've done something naughty as I've been seeing errors for a few days, but I've done some troubleshooting and I can't seem to find the place I shot myself in the foot. My system is current, and about a week old right now. Source was checked out this morning at about 8:30 A.M. EST. The output of uname -a follows. FreeBSD current 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Jun 5 10:34:30 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CURRENT-TWO i386 Leading up to this build I explicitly ran the following commands. cd /usr/src chflags -R noschg /usr/obj/* rm -rf /usr/obj/* make cleandir make cleandir make buildworld The tail end of the build error is below. I have the full build output if anyone would like to see it. Repeated builds, even in single-user mode, all show the same error. I have tried to ensure that nothing in /etc/make.conf is biting me, only a few things are defined, primarily CPUTYPE=i686. I usually run at CPUTYPE=p3 (as p4 builds broken code last I heard) but downgraded here to remove a possible source of error. CFLAGS and CXXFLAGS are not defined. cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd -DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 -DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ -DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -std=iso9899:1999 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/stab-syms.c -o stab-syms.o cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd -DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 -DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ -DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -std=iso9899:1999 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/stabs.c -o stabs.o cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd -DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 -DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ -DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -std=iso9899:1999 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/syms.c -o syms.o cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec -I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd -DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 -DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ -DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -std=iso9899:1999 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/targets.c -o targets.o In file included from /usr/src/contrib/binutils/bfd/targets.c:1092: targmatch.h:7:1: null character(s) ignored targmatch.h:12:1: null character(s) ignored targmatch.h:16:1: null character(s) ignored targmatch.h:20:1: null character(s) ignored targmatch.h:24:1: null character(s) ignored hundreds of lines between here have been snipped targmatch.h:2024:1: null character(s) ignored targmatch.h:2028:1: null character(s) ignored targmatch.h:2033:1: null character(s) ignored
Re: Bulding libc.so with gnu99 is dangerous!
On Fri, Jun 13, 2003 at 12:44:27 -0700, David O'Brien wrote: On Fri, Jun 13, 2003 at 07:40:53PM +0400, Andrey Chernov wrote: After installing libc.so builded with standard bsd.sys.mk (i.e. with gnu99) all shared programs reports missing 'SYS_sigreturn' name and fails to start. When I restore old libc and rebuild libc without gnu99, all works fine again. Please provide sufficent detail that I can track down your problem. The problem itself is gone with updating to new bsd.sys.mk where now CSTD?= c99 for i386, but some time ago there was CSTD?= gnu99 for i386 and I just build/install libc to trigger the bug. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld failing in /usr/src/gnu/usr.bin/binutils/libbfd
On Fri, Jun 13, 2003 at 03:42:20PM -0400, Fish wrote: Hello list, I'm sure I've done something naughty as I've been seeing errors for a few days, but I've done some troubleshooting and I can't seem to find the place I shot myself in the foot. This is getting a FAQ; I'll add an entry to UPDATING. There was a small window in which sed(1) was broken. If you happen to have installed sed(1) during that window, which you apparently have, you need to manually build and install sed(1) (and only sed(1))\ before doing anything else. Would someone please tell me exactly what stupid thing I'm doing today? You forgot to search the mailing list :-) -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Buildworld failing in /usr/src/gnu/usr.bin/binutils/libbfd
On 13 Jun 2003 15:42:20 -0400, Fish [EMAIL PROTECTED] wrote: Hello list, I'm sure I've done something naughty as I've been seeing errors for a few days, but I've done some troubleshooting and I can't seem to find the place I shot myself in the foot. My system is current, and about a week old right now. Source was checked out this morning at about 8:30 A.M. EST. The output of uname -a follows. FreeBSD current 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Thu Jun 5 10:34:30 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CURRENT-TWO i386 Leading up to this build I explicitly ran the following commands. cd /usr/src chflags -R noschg /usr/obj/* rm -rf /usr/obj/* make cleandir make cleandir make buildworld The tail end of the build error is below. I have the full build output if anyone would like to see it. Repeated builds, even in single-user mode, all show the same error. I have tried to ensure that nothing in /etc/make.conf is biting me, only a few things are defined, primarily CPUTYPE=i686. I usually run at CPUTYPE=p3 (as p4 builds broken code last I heard) but downgraded here to remove a possible source of error. CFLAGS and CXXFLAGS are not defined. cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 - I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec - I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd - DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 - DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ - DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -std=iso9899:1999 -Wsystem-headers -Werror -Wall - Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer- arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/stab-syms.c -o stab-syms.o cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 - I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec - I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd - DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 - DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ - DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -std=iso9899:1999 -Wsystem-headers -Werror -Wall - Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer- arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/stabs.c -o stabs.o cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 - I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec - I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd - DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 - DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ - DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -std=iso9899:1999 -Wsystem-headers -Werror -Wall - Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer- arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/syms.c -o syms.o cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I. -I/usr/src/gnu/usr.bin/binutils/libbfd/i386 -I/usr/src/gnu/usr.bin/binutils/libbfd -I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386 - I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include -DDEFAULT_VECTOR=bfd_elf32_i386_freebsd_vec - I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd - DBFD_VERSION=\20021127\ -DBFD_VERSION_DATE=20021127 - DBFD_VERSION_STRING=\2.13.2 [FreeBSD] 2002-11-27\ - DSELECT_ARCHITECTURES= bfd_i386_arch -DHAVE_bfd_elf32_i386_freebsd_vec -DHAVE_bfd_elf32_i386_vec -DSELECT_VECS= bfd_elf32_i386_freebsd_vec ,bfd_elf32_i386_vec -std=iso9899:1999 -Wsystem-headers -Werror -Wall - Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer- arith -Wno-uninitialized -c /usr/src/contrib/binutils/bfd/targets.c -o targets.o In file included from /usr/src/contrib/binutils/bfd/targets.c:1092: targmatch.h:7:1: null character(s) ignored targmatch.h:12:1: null character(s) ignored targmatch.h:16:1: null character(s) ignored targmatch.h:20:1: null character(s) ignored targmatch.h:24:1: null character(s) ignored hundreds of lines between here have been snipped targmatch.h:2024:1: null character(s) ignored
Re: rpc.yppasswdd failed in FreeBSD 5.1
In the last episode (Jun 13), Lin, Tsung Ching said: hello, I setup a NIS Master in FreeBSD 5.1 release, and it works. I also startup rpc.yppasswdd. When I wnat to change a user's passwd using yppasswd, it failed. root# passwd testuser Changing NIS password for testuser Old Password: New Password: Retype New Password: passwd: pam_chauthtok(): error in service module Jun 13 22:22:24 abcb passwd: in pam_sm_chauthtok(): yppasswd_local(): failed to connect to rpc.yppasswdd: .xxx.xxx.xxx: RPC: Program not registered Does it work if you run from another NIS client machine? -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: *IT WORKS* Re: CardBus USB 2.0 Controller (NEC uPD)
On Fri, 2003-06-13 at 14:17, Tony Naggs wrote: Yes, I think you should also do this for Uhci. There are probably not many straight Uhci USB 1.1 Cardbus cards, but it is likely some of the USB 2.0 cards have an UHCI controller rather than OHCI for USB 1.x support. Never mind, it seems Warner was one step ahead of us and committed a similar change to uhci_pci.c two days ago :) Craig ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build flags for a 386DX (5.1)
On Fri, Jun 13, 2003 at 12:44:06PM -0700, Doug White wrote: On Thu, 12 Jun 2003, John Nielsen wrote: [escalated from -questions] Hi folks- I am setting up FreeBSD 5.1-RELEASE on a 386DX. That works? 386 is not a supported CPU on 5.X. It is missing atomic operations that is necesary for proper operation of threading. It is if you compile your own kernel, it's just not supported by default. Kris pgp0.pgp Description: PGP signature
Re: build flags for a 386DX (5.1)
On Friday 13 June 2003 15:02, Kris Kennaway wrote: On Fri, Jun 13, 2003 at 12:44:06PM -0700, Doug White wrote: On Thu, 12 Jun 2003, John Nielsen wrote: [escalated from -questions] Hi folks- I am setting up FreeBSD 5.1-RELEASE on a 386DX. That works? 386 is not a supported CPU on 5.X. It is missing atomic operations that is necesary for proper operation of threading. It is if you compile your own kernel, it's just not supported by default. Yup, it's working fine. I replaced the kernel on the boot floppy with one I had built for the occasion (with 'cpu I386_CPU' and 'options GPL_MATH_EMULATE'). As I indicated, my only hangup is that I'm not familiar enough with the new GCC 3 build procedures to know where to put the -march and/or -mcpu flags for a buildworld on a separate (newer) machine. JN ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on sparc64/sparc64
TB --- 2003-06-13 20:30:15 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-06-13 20:30:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-13 20:32:42 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-13 21:24:50 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Fri Jun 13 21:24:50 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/en. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2003-06-13 21:30:40 - /usr/bin/make returned exit code 1 TB --- 2003-06-13 21:30:40 - ERROR: failed to build generic kernel TB --- 2003-06-13 21:30:40 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bulding libc.so with gnu99 is dangerous!
On Fri, Jun 13, 2003 at 11:51:28PM +0400, Andrey Chernov wrote: On Fri, Jun 13, 2003 at 12:44:27 -0700, David O'Brien wrote: On Fri, Jun 13, 2003 at 07:40:53PM +0400, Andrey Chernov wrote: After installing libc.so builded with standard bsd.sys.mk (i.e. with gnu99) all shared programs reports missing 'SYS_sigreturn' name and fails to start. When I restore old libc and rebuild libc without gnu99, all works fine again. Please provide sufficent detail that I can track down your problem. The problem itself is gone with updating to new bsd.sys.mk where now CSTD?= c99 for i386, but some time ago there was CSTD?= gnu99 for i386 and I just build/install libc to trigger the bug. This isn't a bug report. The mail server I am writing this from, and the laptop I am using to log into it from; are running with a stock world and I can't repeat your problem. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bulding libc.so with gnu99 is dangerous!
On Fri, Jun 13, 2003 at 14:53:07 -0700, David O'Brien wrote: This isn't a bug report. The mail server I am writing this from, and the laptop I am using to log into it from; are running with a stock world and I can't repeat your problem. Exact steps are (on i386-current from Jun 1, cvsupped to recent, includes installed): setenv CSTD gnu99 cd /usr/src/lib/libc; make; make install (using compiler builded at Jun 1) This is not stock world bug report, since recent world have c99 instead of gnu99 on i386. This is about dangerous gnu99 option on i386. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: redirect unauthorized users to a login page (natd as atransparent proxy)
On Tue, Jun 10, 2003 at 11:53:48AM +0200, Vaclav Petricek wrote: [...] The patch works. Thank you very much. I attach my attempt on a patch that should make it possible to ommit the alias_address and interface options in case proxy_only is specified. IMHO in that situation these options are not used and should not be required by natd.. Certainly. I've committed a variation of your patch to natd.c, and the corresponding documentation changes to natd.8. MFC is planned in two weeks (see attached). Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer ---BeginMessage--- ru 2003/06/13 15:15:42 PDT FreeBSD src repository Modified files: sbin/natdnatd.8 natd.c Log: If the -proxy_only option is used, the -alias_address/-interface options are not required. Suggested by: Vaclav Petricek MFC after: 2 weeks Revision ChangesPath 1.58 +5 -2 src/sbin/natd/natd.8 1.42 +4 -2 src/sbin/natd/natd.c ---End Message--- pgp0.pgp Description: PGP signature
CSTD=c99 considered harmful (Re: adsl/pppoe no longer connecting on5.1)
On Thu, Jun 12, 2003 at 03:08:53PM -0700, David O'Brien wrote: On Wed, Jun 11, 2003 at 10:32:30PM -0700, Kris Kennaway wrote: alloca() is not being inlined when -std is specified. It is possible there's a bug in the libc implementation. I'm also suspicious that some of the ppp data structures have changed size or alignment which could be confusing netgraph. Acutally -std=c?9, -std=gnu?9 uses GCC's alloca. I don't mind finding all the alloca uses in the tree and compiling them with -std=gnu99 instead of -std=c99. In the meantime, 5.1 is still broken for lots of people. Please back out the use of CSTD=c99 until these problems can be resolved. Kris pgp0.pgp Description: PGP signature
Re: rpc.yppasswdd failed in FreeBSD 5.1
Lin, Tsung Ching [EMAIL PROTECTED] writes: passwd: pam_chauthtok(): error in service module Jun 13 22:22:24 abcb passwd: in pam_sm_chauthtok(): yppasswd_local(): failed to connect to rpc.yppasswdd: .xxx.xxx.xxx: RPC: Program not registered This means that rpc.yppasswdd isn't running on the server. Try 'rpcinfo -p server-name' to find out for sure. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: build flags for a 386DX (5.1)
John Nielsen [EMAIL PROTECTED] writes: As I indicated, my only hangup is that I'm not familiar enough with the new GCC 3 build procedures to know where to put the -march and/or -mcpu flags for a buildworld on a separate (newer) machine. Put CPUTYPE?=i386 in /etc/make.conf and rebuild world. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
buildkernel error in 5.1_RELEASE
I have downloaded the 5.1-RELEASE source via sysinstall and while world build fine, I have this error when trying to compile a new kernel from the downloaded source on Alpha: cc -c -O -pipe -mcpu=ev45 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL -include opt_global.h -fno-common -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror vers.c linking kernel init_main.o: In function `proc0_init': init_main.o(.text+0x424): undefined reference to `kse0_sched' init_main.o(.text+0x430): undefined reference to `ksegrp0_sched' init_main.o(.text+0x43c): undefined reference to `proc0_sched' init_main.o(.text+0x448): undefined reference to `thread0_sched' *** Error code 1 Stop in /usr/obj/usr/src/sys/AYLEE. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. aylee# uname -a FreeBSD aylee.number6 5.0-RELEASE-p7 FreeBSD 5.0-RELEASE-p7 #0: Mon May 5 23:29:58 EST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/AYLEE alpha cheers, Rob -- When in doubt, fuck it. When not in doubt ... get in doubt! This is random quote 1185 of 1254. Distance from the centre of the brewing universe [15200.8 km (8207.8 mi), 262.8 deg](Apparent) Rennerian Public Key fingerprint = 6219 33BD A37B 368D 29F5 19FB 945D C4D7 1F66 D9C5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildkernel error in 5.1_RELEASE
On Sat, Jun 14, 2003 at 09:06:16AM +1000, Rob B wrote: linking kernel init_main.o: In function `proc0_init': init_main.o(.text+0x424): undefined reference to `kse0_sched' init_main.o(.text+0x430): undefined reference to `ksegrp0_sched' init_main.o(.text+0x43c): undefined reference to `proc0_sched' init_main.o(.text+0x448): undefined reference to `thread0_sched' *** Error code 1 Read /usr/src/UPDATING 20030125: The scheduler framework has grown a second scheduler and consequently you must specify one and only one scheduler in your kernel config. The cvs config files have been updated to use the old scheduler which may be selected via 'options SCHED_4BSD'. If you would like to try the new, much more experimental, scheduler please try 'options SCHED_ULE' and contribute to the arch@ discussion. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: kmem_malloc(4096): kmem_map too small
On Fri, 13 Jun 2003, John Hay wrote:
On a 5.1-RELEASE machine I have been able to cause a panic like this:
panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated
The machine is an old 300MHz Celeron with 64M Ram. I get the panic by
un-taring a huge .tgz file onto a vinum partition which is on a scsi
disk behind a Adaptec 2940 controller. The huge tar file contains a
...
Here follow the output of vinum list and then the panic message and
a gdb traceback. I'm not sure if the traceback is correct. I think
it only show the second panic.
It shows mainly bugs in the debugging :-[.
panic: free locked buf
Debugging bug 1:
The above shows a secondary panic, but is supposed to show the primary
panic. gdb just prints the contents of the kernel panicstr variable,
but the setting of that variable is broken (see below).
panic messages:
---
panic: kmem_malloc(4096): kmem_map too small: 28610560 total allocated
syncing disks, buffers remaining... panic: free locked buf
Uptime: 1h47m5s
(da0:ahc0:0:6:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0
(da0:ahc0:0:6:0): error code 54
Dumping 64 MB
ata0: resetting devices ..
done
16 32 48
---
Debugging bug 2:
gdb then prints the contents of the message buffer starting with the
regexp ^(panic:|Fatal trap) . It just uses system(dmesg ... | awk ...).
Eeek. This may start with a panic for a previous boot and print all
messages in the buffer for subsequent boots. This doesn't happen here.
Reading symbols from
/usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug...done.
Loaded symbols for
/usr/src/sys/i386/compile/TRY/modules/usr/src/sys/modules/vinum/vinum.ko.debug
#0 doadump () at ../../../kern/kern_shutdown.c:238
238 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:238
#1 0xc01ab1ca in boot (howto=260) at ../../../kern/kern_shutdown.c:370
#2 0xc01ab483 in panic () at ../../../kern/kern_shutdown.c:543
#3 0xc1064926 in freerq (rq=0xc166c4c0)
at /usr/src/sys/dev/vinum/vinuminterrupt.c:252
#4 0xc106482a in complete_rqe (bp=0xc12a6c24)
at /usr/src/sys/dev/vinum/vinuminterrupt.c:230
#5 0xc01eda81 in bufdone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:3086
#6 0xc01ed984 in bufdonebio (bp=0x0) at ../../../kern/vfs_bio.c:3034
#7 0xc01ed7e2 in biodone (bp=0xc12a6c24) at ../../../kern/vfs_bio.c:2961
#8 0xc017d4be in g_dev_done (bp2=0xc1552120) at ../../../geom/geom_dev.c:391
#9 0xc01ed7e2 in biodone (bp=0xc1552120) at ../../../kern/vfs_bio.c:2961
#10 0xc017fc62 in g_io_schedule_up (tp=0xc0607e40)
at ../../../geom/geom_io.c:365
#11 0xc017fe58 in g_up_procbody () at ../../../geom/geom_kern.c:91
#12 0xc01986ce in fork_exit (callout=0xc017fe30 g_up_procbody, arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:768
(kgdb) quit
Debugging bug 3:
The primary panic occurred in another thread, and we just got here to
sync() for the other thread. Then we soon paniced with free locked buf.
Thus there is no trace of the primary panic in this frame and no
secondary or tertiary panics in this frame. freerq() just paniced in
BUF_LOCKFREE() and the panic didn't try syncing again since it is
recursive (not actually recursive since it is in a diferent thread).
You need to look at other threads to see where the primary panic occurred.
panic() doesn't understand that it may be called from more than 1 thread
(it shouldn't be), so it doesn't print any hints its callers.
Debugging bug 1 (continued):
The setting of `panicstr' was broken in rev.1.38:
% void
% panic(const char *fmt, ...)
% {
% struct thread *td = curthread;
% int bootopt, newpanic;
% va_list ap;
% static char buf[256];
%
% #ifdef SMP
% ...
% #endif
%
% bootopt = RB_AUTOBOOT | RB_DUMP;
% newpanic = 0;
% if (panicstr)
% bootopt |= RB_NOSYNC;
% else {
% panicstr = fmt;
^^
This sets panicstr for the original panic only.
% newpanic = 1;
% }
%
% va_start(ap, fmt);
% (void)vsnprintf(buf, sizeof(buf), fmt, ap);
% if (panicstr == fmt)
% panicstr = buf;
^^
This gives a more useful setting of panicstr (rev.1.38). Unfortunately,
it points panicstr at static storage which is clobbered by secondary
panics.
% va_end(ap);
% printf(panic: %s\n, buf);
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bluetooth 20030604 and 5.1 release
Hello again, all information you have given me has been very helpful. ButI have messed up somewhere while setting up the rcfomm_pppd section and I don't know where the problem is. I have setup my ppp.conf like this: default: nat enable yes set ifaddr 192.168.0.1/0 192.168.0.2/0 bluetooth: enable dns disable pap deny pap disable chap deny chap verizon: set log Phase tun command set device PPPoE:fxp0 set authname blahblah set authkey blahblah set dal //above is set dial, not dal set login the output from hcidump when my other computer tries to make a LAN connection over PPP is: HCIDump - HCI packet analyzer ver 1.4 device: any snap_len: 65535 filter: 0x HCI Event: Connect Request(0x04) plen 10 HCI Command: Accept Connection Request(0x01|0x0009) plen 7 HCI Event: Command Status(0x0f) plen 4 HCI Event: Role Change(0x12) plen 8 HCI Event: Connect Complete(0x03) plen 11 HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 HCI Event: Command Complete(0x0e) plen 6 ACL data: handle 0x0006 flags 0x02 dlen 12 L2CAP(s): Connect req: psm 3 scid 0x0040 ACL data: handle 0x0006 flags 0x02 dlen 16 L2CAP(s): Connect rsp: dcid 0x004f scid 0x0040 result 0 status 0 HCI Event: Number of Completed Packets(0x13) plen 5 ACL data: handle 0x0006 flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x004f flags 0x clen 4 MTU 32767 ACL data: handle 0x0006 flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x0040 flags 0x result 0 clen 0 ACL data: handle 0x0006 flags 0x02 dlen 16 L2CAP(s): Config req: dcid 0x0040 flags 0x clen 4 MTU 132 HCI Event: Number of Completed Packets(0x13) plen 5 HCI Event: Role Change(0x12) plen 8 ACL data: handle 0x0006 flags 0x02 dlen 14 L2CAP(s): Config rsp: scid 0x004f flags 0x result 0 clen 0 ACL data: handle 0x0006 flags 0x02 dlen 8 L2CAP(d): cid 0x4f len 4 [psm 3] RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c ACL data: handle 0x0006 flags 0x02 dlen 8 L2CAP(d): cid 0x40 len 4 [psm 3] RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7 HCI Event: Number of Completed Packets(0x13) plen 5 ACL data: handle 0x0006 flags 0x02 dlen 17 ACL data: handle 0x0006 flags 0x01 dlen 1 L2CAP(d): cid 0x4f len 14 [psm 3] RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8 dlci 2 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_size 127 max_re trans 0 credits 0 ACL data: handle 0x0006 flags 0x02 dlen 8 L2CAP(d): cid 0x40 len 4 [psm 3] RFCOMM(s): DM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x73 HCI Event: Number of Completed Packets(0x13) plen 5 Also, let me explain cleary what I am trying to do so you can tell me if my understanding is wrong. I am using my FreeBSD box with a bluetooth adaptor to serve internet connections to other devices, my laptop specifically. So I did hcsecd, then sdptool add --channel=1 LAN then rfcomm_pppd -a mylaptopaddress -s -C 1 -l bluetooth These are all the steps I took to get this to work. The items are already paired. Does anyone know where I am making a wrong step? The laptop I am using to connect is MAC OS X, and I found info on the net to connect OSX to a bluetooth PPP over LAN connection says I should do this on my mac: select LAN access using PPP. Select RS232 on Port type. On the Modem tab, select Null Modem 115200 modem profile. I would appreciate it if anyone could help me with this. Thanks ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
rarpd broken on 64bit big endien machines (i.e. sparc64)
Ok, I just tried to net boot an Ultra 2 from another sparc box, and
rarpd is broken. It is still using u_long to represent the IPv4
addresses. Attached is a patch that switches from u_long to in_addr_t.
I have confirmed that this works on both sparc64 (5.1-R) and x86 (4.7-R).
Comments?
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
? rarpd
? rarpd.8.gz
Index: rarpd.c
===
RCS file: /home/ncvs/src/usr.sbin/rarpd/rarpd.c,v
retrieving revision 1.34
diff -u -r1.34 rarpd.c
--- rarpd.c 2003/05/03 21:06:39 1.34
+++ rarpd.c 2003/06/14 01:02:48
@@ -114,8 +114,8 @@
struct if_info {
struct if_info *ii_next;
int ii_fd; /* BPF file descriptor */
- u_long ii_ipaddr; /* IP address of this interface */
- u_long ii_netmask; /* subnet or net mask */
+ in_addr_t ii_ipaddr; /* IP address of this interface */
+ in_addr_t ii_netmask; /* subnet or net mask */
u_char ii_eaddr[6];/* Ethernet address of this interface */
char ii_ifname[sizeof(((struct ifreq *)0)-ifr_name) + 1];
};
@@ -136,22 +136,22 @@
static u_char zero[6];
static int bpf_open(void);
-static u_long choose_ipaddr(u_long **, u_long, u_long);
+static in_addr_t choose_ipaddr(in_addr_t **, in_addr_t, in_addr_t);
static char*eatoa(u_char *);
static int expand_syslog_m(const char *fmt, char **newfmt);
static voidinit(char *);
static voidinit_one(struct ifreq *, char *);
-static char*intoa(u_long);
-static u_long ipaddrtonetmask(u_long);
+static char*intoa(in_addr_t);
+static in_addr_t ipaddrtonetmask(in_addr_t);
static voidlogmsg(int, const char *, ...) __printflike(2, 3);
-static int rarp_bootable(u_long);
+static int rarp_bootable(in_addr_t);
static int rarp_check(u_char *, u_int);
static voidrarp_loop(void);
static int rarp_open(char *);
static voidrarp_process(struct if_info *, u_char *, u_int);
static voidrarp_reply(struct if_info *, struct ether_header *,
- u_long, u_int);
-static voidupdate_arptab(u_char *, u_long);
+ in_addr_t, u_int);
+static voidupdate_arptab(u_char *, in_addr_t);
static voidusage(void);
int
@@ -390,9 +390,9 @@
/* Verbose stuff */
if (verbose)
for (ii = iflist; ii != NULL; ii = ii-ii_next)
- logmsg(LOG_DEBUG, %s %s 0x%08lx %s,
+ logmsg(LOG_DEBUG, %s %s 0x%08x %s,
ii-ii_ifname, intoa(ntohl(ii-ii_ipaddr)),
- (u_long)ntohl(ii-ii_netmask), eatoa(ii-ii_eaddr));
+ (in_addr_t)ntohl(ii-ii_netmask), eatoa(ii-ii_eaddr));
}
void
@@ -625,7 +625,7 @@
* configuration file.
*/
int
-rarp_bootable(u_long addr)
+rarp_bootable(in_addr_t addr)
{
#ifdef HAVE_DIRENT_H
struct dirent *dent;
@@ -636,7 +636,7 @@
char ipname[9];
static DIR *dd = NULL;
- (void)sprintf(ipname, %08lX, (u_long)ntohl(addr));
+ (void)sprintf(ipname, %08X, (in_addr_t)ntohl(addr));
/*
* If directory is already open, rewind it. Otherwise, open it.
@@ -666,8 +666,8 @@
* is on network 'net'; 'netmask' is a mask indicating the network portion
* of the address.
*/
-u_long
-choose_ipaddr(u_long **alist, u_long net, u_long netmask)
+in_addr_t
+choose_ipaddr(in_addr_t **alist, in_addr_t net, in_addr_t netmask)
{
for (; *alist; ++alist)
if ((**alist netmask) == net)
@@ -684,7 +684,7 @@
{
struct ether_header *ep;
struct hostent *hp;
- u_long target_ipaddr;
+ in_addr_t target_ipaddr;
char ename[256];
ep = (struct ether_header *)pkt;
@@ -708,7 +708,7 @@
ename);
return;
}
- target_ipaddr = choose_ipaddr((u_long **)hp-h_addr_list,
+ target_ipaddr = choose_ipaddr((in_addr_t **)hp-h_addr_list,
ii-ii_ipaddr ii-ii_netmask,
ii-ii_netmask);
if (target_ipaddr == 0) {
@@ -748,7 +748,7 @@
} rtmsg;
void
-update_arptab(u_char *ep, u_long ipaddr)
+update_arptab(u_char *ep, in_addr_t ipaddr)
{
int cc;
struct sockaddr_inarp *ar, *ar2;
@@ -802,7 +802,7 @@
* directly connected network (the family is AF_INET in
* this case).
*/
- logmsg(LOG_ERR, bogus link family (%d) wrong net for %08lX?\n,
+ logmsg(LOG_ERR, bogus link family (%d) wrong net for %08X?\n,
ll2-sdl_family, ipaddr);
close(r);
return;
@@ -845,7 +845,7 @@
}
#else
void
-update_arptab(u_char *ep, u_long ipaddr)
Re: bluetooth 20030604 and 5.1 release
Hello, --- User Toyboy [EMAIL PROTECTED] wrote: Hello again, all information you have given me has been very helpful. ButI have messed up somewhere while setting up the rcfomm_pppd section and I don't know where the problem is. I have setup my ppp.conf like this: [section skipped] please take a look at examples in rfcomm_pppd(8) man page. you might want to start with clean ppp.conf and make Bluetooth stuff work then add your existing configuration. the output from hcidump when my other computer tries to make a LAN connection over PPP is: [ skipped ] up until this section everything looks good. ACL data: handle 0x0006 flags 0x02 dlen 17 ACL data: handle 0x0006 flags 0x01 dlen 1 L2CAP(d): cid 0x4f len 14 [psm 3] RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8 dlci 2 frame_type 0 credit_flow 15 pri 0 ack_timer 0 frame_size 127 max_re trans 0 credits 0 ACL data: handle 0x0006 flags 0x02 dlen 8 L2CAP(d): cid 0x40 len 4 [psm 3] RFCOMM(s): DM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x73 this section tells me that remote side wants to open RFCOMM connection on DLCI 2 (RFCOMM channel 1), but FreeBSD rejects this connection (most likely because nothing is listening). Also, let me explain cleary what I am trying to do so you can tell me if my understanding is wrong. I am using my FreeBSD box with a bluetooth adaptor to serve internet connections to other devices, my laptop specifically. So I did hcsecd, then sdptool add --channel=1 LAN then did you run sdpd? you need to run sdpd and then register service with sdptool. also you can verify that service has been registered by issuing sdptool browse ff:ff:ff:00:00:00 and look for LAN service. rfcomm_pppd -a mylaptopaddress -s -C 1 -l bluetooth aha! this is the problem. you misused -a option. in server mode -a tells rfcomm_pppd(8) on which *local* BD_ADDR it should listen. it seems that you have specified *remote* (mylaptopaddress) BD_ADDR. this (*remote*) BD_ADDR does not exists on FreeBSD, so connection will never be accepted. in general server application should listen on ANY BD_ADDR, i.e. accept connection via any local device. so what you should do is remove -a option completely, .i.e. rfcomm_pppd -s -C 1 -l bluetooth this will make rfcomm_pppd(8) accept connection from any local device. its all in the man page. These are all the steps I took to get this to work. The items are already paired. Does anyone know where I am making a wrong step? The laptop I am using to connect is MAC OS X, and I found info on the net to connect OSX to a bluetooth PPP over LAN connection says I should do this on my mac: select LAN access using PPP. Select RS232 on Port type. On the Modem tab, select Null Modem 115200 modem profile. can you discover services on your MAC laptop? do you see FreeBSD? do you see LAN service on FreeBSD? if not then you did not setup sdpd on FreeBSD properly. thanks, max __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bulding libc.so with gnu99 is dangerous!
On Sat, 14 Jun 2003, Andrey Chernov wrote: On Fri, Jun 13, 2003 at 14:53:07 -0700, David O'Brien wrote: This isn't a bug report. The mail server I am writing this from, and the laptop I am using to log into it from; are running with a stock world and I can't repeat your problem. Exact steps are (on i386-current from Jun 1, cvsupped to recent, includes installed): setenv CSTD gnu99 cd /usr/src/lib/libc; make; make install (using compiler builded at Jun 1) This is not stock world bug report, since recent world have c99 instead of gnu99 on i386. This is about dangerous gnu99 option on i386. As reported previously, CSTD=gnu99 make in lib/msun breaks things in a more obvious way (at compile time). std=gnu99 apparently breaks __CONCAT(). Bruce ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
VIA C3
Anyone have a VIA C3? I'm running FreeBSD current on one and I don't see any gcc flags for the VIA C3. I think it has MMX and 3dnow, but it does not have SSE? I was wondering what gcc flags other VIA C3 users are using on FreeBSD. I am not sure what optimizations are safe for this cpu running FreeBSD. Maybe it would be useful to have a CPUTYPE entry for the VIA C3? CPU: VIA/IDT Unknown (998.70-MHz 686-class CPU) Origin = CentaurHauls Id = 0x689 Stepping = 9 Features=0x803035FPU,DE,TSC,MSR,MTRR,PGE,MMX Regards, David Yeske __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.yppasswdd failed in FreeBSD 5.1
¦b ??, 2003-06-14 04:08, Dan Nelson ¼g¹D¡G In the last episode (Jun 13), Lin, Tsung Ching said: hello, I setup a NIS Master in FreeBSD 5.1 release, and it works. I also startup rpc.yppasswdd. When I wnat to change a user's passwd using yppasswd, it failed. root# passwd testuser Changing NIS password for testuser Old Password: New Password: Retype New Password: passwd: pam_chauthtok(): error in service module Jun 13 22:22:24 abcb passwd: in pam_sm_chauthtok(): yppasswd_local(): failed to connect to rpc.yppasswdd: .xxx.xxx.xxx: RPC: Program not registered Does it work if you run from another NIS client machine? yes, i did. But it still not worked. by the way, I am sure rpc.yppasswd had registered to rpcbind. root# rpcinfo -p abcb program vers proto port 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 104 7111 portmapper 103 7111 portmapper 102 7111 portmapper 141 udp 1021 ypserv 142 udp 1021 ypserv 141 tcp 1023 ypserv 142 tcp 1023 ypserv 172 udp 1020 ypbind 172 tcp 1022 ypbind 191 udp 1014 yppasswdd 191 tcp 1020 yppasswdd 600191 udp 1014 600191 tcp 1020 132 udp 2049 nfs 151 udp 1011 mountd 153 udp 1011 mountd 151 tcp 1019 mountd 153 tcp 1019 mountd 133 udp 2049 nfs 132 tcp 2049 nfs 133 tcp 2049 nfs 1000241 udp 1008 status 1000241 tcp 1016 status 1000210 udp 1007 nlockmgr 1000211 udp 1007 nlockmgr 1000213 udp 1007 nlockmgr 1000214 udp 1007 nlockmgr 1000210 tcp 1015 nlockmgr 1000211 tcp 1015 nlockmgr 1000213 tcp 1015 nlockmgr 1000214 tcp 1015 nlockmgr ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: rpc.yppasswdd failed in FreeBSD 5.1
¦b ??, 2003-06-14 06:54, Dag-Erling Smorgrav ¼g¹D¡G Lin, Tsung Ching [EMAIL PROTECTED] writes: passwd: pam_chauthtok(): error in service module Jun 13 22:22:24 abcb passwd: in pam_sm_chauthtok(): yppasswd_local(): failed to connect to rpc.yppasswdd: .xxx.xxx.xxx: RPC: Program not registered This means that rpc.yppasswdd isn't running on the server. Try 'rpcinfo -p server-name' to find out for sure. DES I am sure rpc.yppasswdd did register to rpcbind. here are the results. thank you very much. tsungching:~# rpcinfo -p abcb program vers proto port 104 tcp111 portmapper 103 tcp111 portmapper 102 tcp111 portmapper 104 udp111 portmapper 103 udp111 portmapper 102 udp111 portmapper 104 7111 portmapper 103 7111 portmapper 102 7111 portmapper 141 udp 1021 ypserv 142 udp 1021 ypserv 141 tcp 1023 ypserv 142 tcp 1023 ypserv 172 udp 1020 ypbind 172 tcp 1022 ypbind 191 udp 1014 yppasswdd 191 tcp 1020 yppasswdd 600191 udp 1014 600191 tcp 1020 132 udp 2049 nfs 151 udp 1011 mountd 153 udp 1011 mountd 151 tcp 1019 mountd 153 tcp 1019 mountd 133 udp 2049 nfs 132 tcp 2049 nfs 133 tcp 2049 nfs 1000241 udp 1008 status 1000241 tcp 1016 status 1000210 udp 1007 nlockmgr 1000211 udp 1007 nlockmgr 1000213 udp 1007 nlockmgr 1000214 udp 1007 nlockmgr 1000210 tcp 1015 nlockmgr 1000211 tcp 1015 nlockmgr 1000213 tcp 1015 nlockmgr 1000214 tcp 1015 nlockmgr Lin, Tsung Ching ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Freebsd 4.7 to 5.1 buildworld failed! (fwd)
Hello, I did a cvsup and retrieved tag=RELENG_5_1_0_RELEASE. Then try to buildworld and got this error. :/usr/src# make buildworld Running test variables PASS: Test variables detected no regression, output matches. Running test targets PASS: Test targets detected no regression. Running test sysvmatch PASS: Test sysvmatch detected no regression. Running test lhs_expn FAIL: Test failed: regression detected. See above. *** Error code 1 Stop in /usr/src/tools/regression/usr.bin/make. *** Error code 1 Stop in /usr/src/tools/regression/usr.bin/make. -- Building an up-to-date make(1) -- rm -f .depend mkdep -f .depend -a-I/usr/src/usr.bin/make -DMAKE_VERSION=\5200209170\ -D__FBSDID=__RCSID -DDEFSHELL=1 /usr/src/usr.bin/make/arch.c /usr/src/usr.bin/make/buf.c /usr/src/usr.bin/make/compat.c /usr/src/usr.bin/make/cond.c /usr/src/usr.bin/make/dir.c /usr/src/usr.bin/make/for.c /usr/src/usr.bin/make/hash.c /usr/src/usr.bin/make/job.c /usr/src/usr.bin/make/main.c /usr/src/usr.bin/make/make.c /usr/src/usr.bin/make/parse.c /usr/src/usr.bin/make/str.c /usr/src/usr.bin/make/suff.c /usr/src/usr.bin/make/targ.c /usr/src/usr.bin/make/util.c /usr/src/usr.bin/make/var.c /usr/src/usr.bin/make/var_modify.c /usr/src/usr.bin/make/lst.lib/lstAppend.c /usr/src/usr.bin/make/lst.lib/lstAtEnd.c /usr/src/usr.bin/make/lst.lib/lstAtFront.c /usr/src/usr.bin/make/lst.lib/lstClose.c /usr/src/usr.bin/make/lst.lib/lstConcat.c /usr/src/usr.bin/make/lst.lib/lstDatum.c /usr/src/usr.bin/make/lst.lib/lstDeQueue.c /usr/src/usr.bin/make/lst.lib/lstDestroy.c /usr/src/usr.bin/make/lst.lib/lstDupl.c /usr/src/usr.bin/make/lst.lib/lstEnQueue.c /usr/src/usr.bin/make/lst.lib/lstFind.c /usr/src/usr.bin/make/lst.lib/lstFindFrom.c /usr/src/usr.bin/make/lst.lib/lstFirst.c /usr/src/usr.bin/make/lst.lib/lstForEach.c /usr/src/usr.bin/make/lst.lib/lstForEachFrom.c /usr/src/usr.bin/make/lst.lib/lstInit.c /usr/src/usr.bin/make/lst.lib/lstInsert.c /usr/src/usr.bin/make/lst.lib/lstIsAtEnd.c /usr/src/usr.bin/make/lst.lib/lstIsEmpty.c /usr/src/usr.bin/make/lst.lib/lstLast.c /usr/src/usr.bin/make/lst.lib/lstMember.c /usr/src/usr.bin/make/lst.lib/lstNext.c /usr/src/usr.bin/make/lst.lib/lstOpen.c /usr/src/usr.bin/make/lst.lib/lstRemove.c /usr/src/usr.bin/make/lst.lib/lstReplace.c /usr/src/usr.bin/make/lst.lib/lstSucc.c In file included from /usr/src/usr.bin/make/cond.c:55: /usr/include/math.h:20: sys/_types.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.bin/make. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. At first I was getting the libpthread error everyone seems to be getting but now I got this error(after i removed /usr/src and /usr/obj, and cvsup using HEAD). Can someone please point me in the right direction. Thanks Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Freebsd 4.7 to 5.1 buildworld failed!
Hello, I did a cvsup and retrieved tag=RELENG_5_1_0_RELEASE. Then try to buildworld and got this error. :/usr/src# make buildworld Running test variables PASS: Test variables detected no regression, output matches. Running test targets PASS: Test targets detected no regression. Running test sysvmatch PASS: Test sysvmatch detected no regression. Running test lhs_expn FAIL: Test failed: regression detected. See above. *** Error code 1 Stop in /usr/src/tools/regression/usr.bin/make. *** Error code 1 Stop in /usr/src/tools/regression/usr.bin/make. -- Building an up-to-date make(1) -- rm -f .depend mkdep -f .depend -a-I/usr/src/usr.bin/make -DMAKE_VERSION=\5200209170\ -D__FBSDID=__RCSID -DDEFSHELL=1 /usr/src/usr.bin/make/arch.c /usr/src/usr.bin/make/buf.c /usr/src/usr.bin/make/compat.c /usr/src/usr.bin/make/cond.c /usr/src/usr.bin/make/dir.c /usr/src/usr.bin/make/for.c /usr/src/usr.bin/make/hash.c /usr/src/usr.bin/make/job.c /usr/src/usr.bin/make/main.c /usr/src/usr.bin/make/make.c /usr/src/usr.bin/make/parse.c /usr/src/usr.bin/make/str.c /usr/src/usr.bin/make/suff.c /usr/src/usr.bin/make/targ.c /usr/src/usr.bin/make/util.c /usr/src/usr.bin/make/var.c /usr/src/usr.bin/make/var_modify.c /usr/src/usr.bin/make/lst.lib/lstAppend.c /usr/src/usr.bin/make/lst.lib/lstAtEnd.c /usr/src/usr.bin/make/lst.lib/lstAtFront.c /usr/src/usr.bin/make/lst.lib/lstClose.c /usr/src/usr.bin/make/lst.lib/lstConcat.c /usr/src/usr.bin/make/lst.lib/lstDatum.c /usr/src/usr.bin/make/lst.lib/lstDeQueue.c /usr/src/usr.bin/make/lst.lib/lstDestroy.c /usr/src/usr.bin/make/lst.lib/lstDupl.c /usr/src/usr.bin/make/lst.lib/lstEnQueue.c /usr/src/usr.bin/make/lst.lib/lstFind.c /usr/src/usr.bin/make/lst.lib/lstFindFrom.c /usr/src/usr.bin/make/lst.lib/lstFirst.c /usr/src/usr.bin/make/lst.lib/lstForEach.c /usr/src/usr.bin/make/lst.lib/lstForEachFrom.c /usr/src/usr.bin/make/lst.lib/lstInit.c /usr/src/usr.bin/make/lst.lib/lstInsert.c /usr/src/usr.bin/make/lst.lib/lstIsAtEnd.c /usr/src/usr.bin/make/lst.lib/lstIsEmpty.c /usr/src/usr.bin/make/lst.lib/lstLast.c /usr/src/usr.bin/make/lst.lib/lstMember.c /usr/src/usr.bin/make/lst.lib/lstNext.c /usr/src/usr.bin/make/lst.lib/lstOpen.c /usr/src/usr.bin/make/lst.lib/lstRemove.c /usr/src/usr.bin/make/lst.lib/lstReplace.c /usr/src/usr.bin/make/lst.lib/lstSucc.c In file included from /usr/src/usr.bin/make/cond.c:55: /usr/include/math.h:20: sys/_types.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.bin/make. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. At first I was getting the libpthread error everyone seems to be getting but now I got this error(after i removed /usr/src and /usr/obj, and cvsup using HEAD). Can someone please point me in the right direction. Thanks Alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freebsd 4.7 to 5.1 buildworld failed! (fwd)
On Fri, Jun 13, 2003 at 10:03:34PM +, Alejandro Ayala wrote: At first I was getting the libpthread error everyone seems to be getting but now I got this error(after i removed /usr/src and /usr/obj, and cvsup using HEAD). Can someone please point me in the right direction. Have you read /usr/src/UPDATING? -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
bootpd also broke :(
Well, my further diving into netbooting an Ultra 2 I have found that
bootpd doesn't do select too well. It doesn't use fd_set or anything
which for some reason causes it not to function on Sparc. A simple
switch to using FD_* makes it function.
I have also fixed a couple comments that NetBSD had already fixed.
Comments?
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
? bootpd
? bootpd.8.gz
? bootptab.5.gz
? bootpgw/bootpgw
? tools/bootpef/bootpef
? tools/bootpef/bootpef.8.gz
? tools/bootptest/bootptest
? tools/bootptest/bootptest.8.gz
Index: bootpd.c
===
RCS file: /home/ncvs/src/libexec/bootpd/bootpd.c,v
retrieving revision 1.19
diff -u -r1.19 bootpd.c
--- bootpd.c2003/02/05 13:45:25 1.19
+++ bootpd.c2003/06/14 03:06:40
@@ -186,7 +186,8 @@
struct hostent *hep;
char *stmp;
int n, ba_len, ra_len;
- int nfound, readfds;
+ int nfound;
+ fd_set readfds;
int standalone;
#ifdef SA_NOCLDSTOP/* Have POSIX sigaction(2). */
struct sigaction sa;
@@ -503,14 +504,15 @@
/*
* Process incoming requests.
*/
+ FD_ZERO(readfds);
for (;;) {
struct timeval tv;
- readfds = 1 s;
+ FD_SET(s, readfds);
if (timeout)
tv = *timeout;
- nfound = select(s + 1, (fd_set *)readfds, NULL, NULL,
+ nfound = select(s + 1, readfds, NULL, NULL,
(timeout) ? tv : NULL);
if (nfound 0) {
if (errno != EINTR) {
@@ -530,7 +532,7 @@
}
continue;
}
- if (!(readfds (1 s))) {
+ if (!FD_ISSET(s, readfds)) {
if (debug 1)
report(LOG_INFO, exiting after %ld minutes of
inactivity,
actualtimeout.tv_sec / 60);
@@ -667,7 +669,7 @@
}
hlen = haddrlength(bp-bp_htype);
if (hlen != bp-bp_hlen) {
- report(LOG_NOTICE, bad addr len from from %s address %s,
+ report(LOG_NOTICE, bad addr len from %s address %s,
netname(bp-bp_htype),
haddrtoa(bp-bp_chaddr, hlen));
}
@@ -1024,7 +1026,7 @@
/*
* If the destination address was specified explicitly
-* (i.e. the broadcast address for HP compatiblity)
+* (i.e. the broadcast address for HP compatibility)
* then send the response to that address. Otherwise,
* act in accordance with RFC951:
* If the client IP address is specified, use that
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
USB locks on laptops.
While I thought it might be an isolated example, I have several laptops ... all of which lock up their ports when usb devices are connected. Typical messages include: usb3: unrecoverable error, controller halted and usb3: device problem, disabling port 3 ... which is an example from a new laptop with usb2.0, but an older laptop with usb1.0 gives similar messages. Jun 14 00:09:48 canoe /kernel: uhub0: device problem, disabling port 2 Now... on non-portable hardware, usb ports all seem to work. All of my desktop machine's USB ports work just fine with the same hardware. Any ideas? Dave. -- |David Gilbert, Velocet Communications. | Two things can only be | |Mail: [EMAIL PROTECTED] | equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on alpha/alpha
TB --- 2003-06-14 04:00:15 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-06-14 04:00:15 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-14 04:03:14 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-06-14 05:00:35 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jun 14 05:00:35 GMT 2003 [...] /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1502: increment of pointer to unknown structure /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1502: arithmetic on pointer to an incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c: In function `en_ioctl': /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1591: `SIOCATMGETVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1600: `SIOCATMGVCCS' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1606: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/en/midway.c:1607: dereferencing pointer to incomplete type *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules/en. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/modules. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src. TB --- 2003-06-14 05:07:53 - /usr/bin/make returned exit code 1 TB --- 2003-06-14 05:07:53 - ERROR: failed to build generic kernel TB --- 2003-06-14 05:07:53 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vinum and/or geom panic on alpha
On Tuesday, 10 June 2003 at 14:05:11 +0200, Bernd Walter wrote: fatal kernel trap: Stopped at g_dev_strategy+0x44:stq t0,0x20(v0) 0x20 t0=0x1a61da400,v0=0x0 db trace g_dev_strategy() at g_dev_strategy+0x44 launch_requests() at launch_requests+0x390 prologue botch: displacement 128 frame size botch: adjust register offsets? vinumstart() at vinumstart+0x250 prologue botch: displacement 64 frame size botch: adjust register offsets? intr_n() at 0xccec340 Can you check the locals of launch_requests(), please? Thanks Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
LoR with buf system caused by pcm
Looks like my mp3 playback tried to acquire UFS lockmgr lock with the pcm lock held. Also, got a LoR w/ Giant through a page not present trap. Only the backtrace() is hand-transcribed due to it not being in dmesg. My system appears to be working fine and there was no crash. dmesg - pcm0: Intel 82801CA (ICH3) port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at device 31.5 on pci0 pcm0: Cirrus Logic CS4299 AC97 Codec Acquiring lockmgr lock ufs with the following non-sleepablelocks held: exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc37a8a00) locked @ /usr/src/sys/dev/sound/pcm/dsp.c:146 Sleeping on spread with the following non-sleepablelocks held: exclusive sleep mutex pcm0:play:0 (pcm channel) r = 0 (0xc37a8a00) locked @ /usr/src/sys/dev/sound/pcm/dsp.c:146 lock order reversal 1st 0xc37a8a00 pcm0:play:0 (pcm channel) @ /usr/src/sys/dev/sound/pcm/dsp.c:146 2nd 0xc039a0c0 Giant (Giant) @ kern/kern_synch.c:311 Stack backtrace: ...witness_lock _mtx_lock_flags()+0xb1 msleep()+0x6c4 bwait()+0x70 spec_getpages()+0x1d5 spec_vnoperate()+0x18 ffs_getpages()+0x4bc vnode_pager_getpages()+0x77 vm_fault()+0x8f3 trap_pfault()+0xef trap()+0x3ad calltrap()+0x5 --- trap 0xc generic_copyin()+0x32 sndbuf_uiomove()+0xe1 chn_write()+0x10f dsp_write()+0x85 spec_write()+0x190 ... write() syscall() ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
