Re: no /dev/dsp.x
T Kellers wrote: ...and subsequent kernel build/install with device pcm, not only didn't I have any pcm line in my dmesg, but I didn't have any snd_maestro3.ko entries in /boot/kernel... That's pretty weird. Do you have any other snd_* modules in /boot/kernel? You don't have NO_MODULES in /etc/make.conf ? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Turkeys and dynamic linking
To all of you who celebrate Thanksgiving today, I wish you a happy one! And speaking of turkeys, does anyone know how Microsoft handles the performance issues associated with dynamic linking? Do they do anything special, or just ignore the whole thing? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to fix this in 5.1-REL??
Kevin Oberman wrote: ...Because changes are applied that will allow smooth upgrades when the kernel is built after the new system is built, but before it is installed, make world is increasingly unlikely to work... The recent statfs changes demonstrated why the 'makeworld' 'makekernel' sequence sometimes fails :-( But I'm still very fuzzy on why the 'makekernel' 'makeworld' sequence is not recommended in FreeBSD the way it is, for example, in OpenBSD. What does 'buildworld' give us that the new kernel might need? Just a simple example would help me more than anything. Thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How to fix this in 5.1-REL??
Brooks Davis answered: walt asked: What does 'buildworld' give us that the new kernel might need? The correct toolchain including the compiler and config(8). Okay, thanks, that helps. Just thinking out loud about worst-case examples for people who do routinely use 'make world' (like I have for several years). I found out first-hand why installworld quits halfway through when the new executables won't run on the old kernel. I need no further education on that point ;-) I'm thinking, though, that doing 'make kernel' first has a much lower potential for disaster than 'make world': if I reboot after a 'make kernel' and the new kernel won't run on the old world, then all I need to do to recover is to boot the old kernel again and 'make buildworld'. Seems difficult to do any real harm this way. Is this completely wrong-headed? Am I missing something important? (Yes, I know I should just do it the right way every time -- but I'm trying to reason through just why some ways are right and some are wrong.) Thanks for any insights. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
Terry Lambert wrote: Robert M.Zigweid wrote: I'll admit to being mostly a lurker here, but isn't the point of /sbin to be statically linked. That's what the 's' stands for? Second question. This seems to imply that /sbin and /bin both have to have the same behavior? I have no problem with /bin being dynamically linked, but what if I want /bin to be dynamic and /sbin static? Since sbin on System V predated shared libraries on System V, I think maybe this is a reverse assignment of a meaning to the 's'. I was taught by an older fart than Terry that the 's' stands for (S)ingle-user, which is reflected even today in the 'boot -s' switch. Since the single-user is usually the Sysadmin, the association with 'system' is inevitable. The association with 'static' is also inevitable when I think of Sysadmins-I-Have-Known ;0) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
GNOME users should recompile gnomevfs2 after today update
I found that the new statfs changes cause nautilus to crash on startup. The fix is to recompile/reinstall devel/gnomevfs2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
sed behaving badly?
I got this nonsensical error from sed while trying to update python: /usr/bin/sed -i.bak -e 's,/usr/doc/python-docs-,/usr/local/share/doc/python,g' /usr/ports/lang/python/work/Python-2.3.2/Lib/pydoc.py sed: /usr/ports/lang/python/work/Python-2.3.2/Lib/pydoc.py: No such file or directory But the file DOES exist, and furthermore the same port compiles just fine on -CURRENT from November 1. I think the recent changes to sed may have broken something, but I don't know how, exactly. Anyone else seeing this problem? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
gcc -pedantic ?
I'm trying to compile mozilla thunderbird on -current and the configure program stops with this error: checking whether C++ compiler has -pedantic long long bug... yes configure: error: Your compiler appears to have a known bug where long long is miscompiled when using -pedantic. Reconfigure using --disable-pedantic. Is this related to the new gcc update, or is it a long-time incompatibility with linux source code? I'm new at this cross-compiling stuff, you can probably tell. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No sound output for pcm
Harald Schmalzbauer wrote: --Boundary-02=_Nn+R/bAN6Fk+pt3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline Hi all, I can confirm something is wrongwith pcm. I have no sound output with todays kernel, the one some weeks ago I had no= =20 problems. My sound is already working again, is yours? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel hangs at serial port during boot (solved)
walt wrote: sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A boot hangs forever at this point I changed the Plug-n-Play BIOS setting and now it works normally again. I also changed the ACPI-aware-OS BIOS setting to YES and I notice that the acpi.ko module is now loading at boot, which it didn't before. I think this is an old thing that I didn't notice until today, however. What surprised me is that the machine has been working for years with the 'wrong' BIOS setting and just now stopped working. Were there some kernel changes recently which would account for this? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel hangs at serial port during boot
sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A boot hangs forever at this point The previous kernel compiled on July 22 worked fine and I've made no changes to the kernel configuration. I'm using the standard GENERIC.hints files copied to /boot/device.hints, and the previous kernel used irq 4 for the same device with no complaints. I have different machine running today's current kernel which is perfectly happy with the serial ports so there must be something funky about this machine, but I don't know what. Hmm. I see that my working machine prints this dmesg: sio0 port 0x3f8-0x3ff irq 4 on acpi0 so perhaps the difference in machines has something to do with acpi? Anyone else seeing this? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: how to create device nodes when devfs doesn't do it?
Karel J. Bosschaart wrote: Hi, After googling and searching in the mailing list archive I still can't figure out how to make device nodes in -current when devfs doesn't do this automatically. I have an external USB-drive (external 3.5 case with leftover 1.6 GB HD) from which I want to mount /dev/da0s4h. It works fine in -stable, after MAKEDEV'ing the node, but on -current I only get da0s4. Have you tried mounting da0s4h? It may show up in /dev after mounting it. Using disklabel on the external USB drive shows some warnings: phys9911# disklabel da0s4 # /dev/da0s4: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a:72513 634.2BSD 1024 819216 b: 26989272576 swap c: 3324825 63unused0 0 # raw part, don't edit d: 131544 3424684.2BSD 1024 819216 e:49896 4740124.2BSD 1024 819216 g: 716688 5239084.2BSD 1024 819216 h: 2084292 12405964.2BSD 1024 819216 disklabel: partition c doesn't start at 0! disklabel: partition c doesn't cover the whole unit! disklabel: An incorrect partition c may cause problems for standard system utilities My experience is that these warnings can be ignored as long as the drive will mount. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
The behavior of 'who'
Is this the expected output for an unexpected input?: $ who /etc . May 9 03:09 (? ) netconfig?? Jan 10 11:57 () ices Oct 23 13:41 (hosts) bSep 8 18:48 (gnats) Jan 10 11:31 (?) eFeb 18 17:56 (db) much more output snipped ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia kernel driver support for FreeBSD-5.1
Juan Rodriguez Hervella wrote: Hello: I've got a PCI-NVidia Riva TNT 64 video card at home, and I've tried to compile the drivers but it doesn't work, and after changing the source to let the compilation progress, when the module is loaded I've received a kernel panic. Im using FreeBSD-5.1 with XFree86-4.3, what can I do to solve this issue ? I can not run the X system using the nv driver, my computer hangs up. #pciconf -l -v [EMAIL PROTECTED]:12:0:class=0x03 card=0x chip=0x002d10de rev=0x15 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'NV5 TNT2 Model 64 / TNT2 Model 64 Pro' This is my video card, which sounds just like yours. I have it working fine with the native XFree 'nv' module, but two caveats: First, once you have installed the driver from NVidia, your /usr/X11 tree will contain files that prevent the native 'nv' module from working. I was never able to figure out which files were responsible so I finally deleted the entire /usr/X11 tree and reinstalled everything from scratch. Second, you must be very careful which modules you load in your XF86Config. There is at least one module which will prevent everything from working-- unfortuneately I can't remember which one :0( Section Module Load extmod Load xie Load pex5 Load dbe Load record Load xtrap Load speedo # Load glx Load type1 Load freetype EndSection Notice that I have 'glx' commented out -- I think that's the reason I did that, but it was a long time ago. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proof of concept patch for device rearrangement
Poul-Henning Kamp wrote: I have uploaded a proof of concept patch: http://phk.freebsd.dk/patch/fd_dev.patch ...And with this code enabled, it is possible to go from userland to device driver without touching Giant underway. I'm sorry, I can't parse that last sentence. Could you explain in 25 words or less (or 3 lines of code) what it means? 'Giant' is the lock that Alan is trying to get rid of? Thanks! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Buildworld broken at lib/msun
cc -O -pipe -mcpu=pentiumpro -D_IEEE_LIBM -D_ARCH_INDIRECT=i387_ -std=gnu99 -c
i387_e_acos.S -o i387_e_acos.o
{standard input}: Assembler messages:
{standard input}:19: Error: junk `(__ieee754_acos)' after expression
{standard input}:19: Error: junk `(__ieee754_acos)' after expression
*** Error code 1
Now, i387_e_acos.S hasn't changed, so something else is wrong.
When I 'cd /usr/src/lib/msun' and do a make from there it compiles
and assembles just fine. This maybe smells like one of the usual
suspects like awk, sed, sh, and their surly gang ;-)
sed was just repaired yesterday, for example. Maybe it still needs
another tweak?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel broken at linux_sysvec.c
cc1: warnings being treated as errors /usr/src/sys/i386/linux/linux_sysvec.c: In function `linux_elf_modevent': /usr/src/sys/i386/linux/linux_sysvec.c:928: warning: implicit declaration of function `linux_mib_destroy' ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Updated XFree86
CARTER Anthony wrote: Hi, I updated XFree86 this morning after a cvsup using portupgrade -r...did all packages for XFree86 (Server, libraries etc. etc.) I now have a problem with GDM... I can log in as root using the GDM, but if I log in as another user, it pops a message up about my session not lasting longer than 10 seconds and dumping me back to login. I get a client 5 rejected from local host in my logs, and I get a run_session_chiled: Could not open ~/.xsession-errors on the console (even though it exists)... I have vague recollections that your ~/.xsession should be marked executable for xdm/gdm/kdm to work properly. Is it? I can't recall if there is a special group added to /etc/group for the xsession manager but if there is one your users may need to belong to that group. Does gdm run SUID? Can't recall, but it may need to. If 'startx' works then I assume you have 'wrapper' installed. I'm not sure about the interaction of wrapper with gdm but you could try de-installing it. Only takes a second to re-install it. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree86-4.3.0,1 +wrapper-1.0_2
CARTER Anthony wrote: Xfree requires wrapper but seems to break GDM for user logins. Is this normal, and can I force un-install wrapper without breaking anything? Excuse me, I'm a bonehead. You don't need to uninstall wrapper, just change this symbolic link: /usr/X11R6/bin/X@ - Xwrapper-4 to this: /usr/X11R6/bin/X@ - XFree86 This *will* break 'startx' for ordinary users. 'Wrapper' is intended to replace xdm and friends to create the .Xauthority in your home directory. If xdm/gdm/kdm don't create the .Xauthority file then something else must do it -- that something else is 'wrapper'. You don't need to use both gdm and wrapper. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why did INVARIANTS hide the geom bug?
Dag-Erling Smørgrav wrote: walt [EMAIL PROTECTED] writes: ... Looking thru sys/geom I don't see any such ifdefs in your code, so I still don't know why the recent geom bug was hidden by INVARIANTS. On the contrary, there is a lot on INVARIANTS-specific code in GEOM: [EMAIL PROTECTED] /sys/geom% grep -r KASSERT . | wc -l 120 Thanks. That was a good explanation in only one line of code ;0) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Why did INVARIANTS hide the geom bug?
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], walt writes: If inclusion of INVARIANTS serves to disguise bugs in the kernel, I wonder if kernel committers should be using this option routinely? Please check into our current reality :-) Hm. How do I parse that sentence? If you are implying (as it says in NOTES) that INVARIANTS are not enabled by default then my question is certainly a stupid one. However, when I look at the GENERIC kernel config file I see options INVARIANTS options INVARIANT_SUPPORT so what am I to think? Do most kernel committers run a GENERIC kernel as the FBSD website says? Does anyone take a poll occasionally? Did I miss your point entirely? Suggest you check what INVARIANTS actually do. Looking at the code thru my amateur eyes it appears that defining INVARIANTS allows the programmer to add whatever code he wishes with an ifdef statement. That covers a lot of territory. Looking thru sys/geom I don't see any such ifdefs in your code, so I still don't know why the recent geom bug was hidden by INVARIANTS. Hope you're feeling better :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on boot (devfs_find)
Bryan Liesner wrote: On Sun, 16 Mar 2003, Poul-Henning Kamp wrote: One thing I'd like you to try is to remove any trace of USB from your systems. USB does some ugly VOP_REVOKES which I am not happy about, and I would like to exclude them from the list of suspects. You can remove USB from your list, I tried building without USB in the kernel, and the panic remains... Which of these flags have you been using?: #cpuI486_CPU #cpuI586_CPU cpu I686_CPU I normally use only the 686 flag, but when I included the 586 my panic-on-boot changed to a panic-on-starting-X. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Why did INVARIANTS hide the geom bug?
If inclusion of INVARIANTS serves to disguise bugs in the kernel, I wonder if kernel committers should be using this option routinely? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
if_iso88025subr.c: doesn't compile.
So far today this file has been updated four times and it still won't compile. Can this be debugged off-line before being committed? I'm trying to debug another problem and I haven't been able to work on it all day because of this problem. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM_MBR breaks my kernel
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], walt writes: I've been unable to boot any kernel I've built since about March 11 and I've narrowed it down to the GEOM_MBR option. With GEOM_MBR I get a kernel page fault error when trying to mount the root filesystem at boot time. Can you get us the messages and a traceback ? Well, no. I've been trying to find a kernel configuration that will allow me to reproduce the bug AND generate a traceback, but so far I can't find one. The problem is that just adding GEOM_MBR to a GENERIC kernel doesn't produce the bug. My normal custom kernel doesn't contain the debugging stuff, and if I start changing things the bug doesn't show. The only semi-interesting result I've come up with is this: I normally use only the 'cpu I686_CPU' flag because I have an Athlon cpu. But if I also include the 'cpu I586_CPU' flag the bug completely changes: the machine boots and the filesystems mount just fine but about ten seconds after I start X running the machine panics and reboots shortly thereafter. The panic message doesn't appear on the screen because the console is not visible at that point. Does this suggest a gcc problem? I've never really understood how more than one 'cpu' flag can be included in the kernel config file, so I'm not sure what actually changes when I do that. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM_MBR breaks my kernel
I've been unable to boot any kernel I've built since about March 11 and I've narrowed it down to the GEOM_MBR option. With GEOM_MBR I get a kernel page fault error when trying to mount the root filesystem at boot time. ad0: 76319MB WDC WD800JB-00CRA1 [155061/16/63] at ata0-master UDMA100 ad1: 76319MB ST380021A [155061/16/63] at ata0-slave UDMA100 acd0: CDROM LTN301 at ata1-master PIO4 MBREXT Slice 5 on ad0s2: [0] f:00 typ:7 s(CHS):6/1/66 e(CHS):250/254/255 s:64 l:12161141 [1] f:00 typ:5 s(CHS):251/0/193 e(CHS):255/254/255 s:12161205 l:20980890 MBREXT Slice 6 on ad0s2: [0] f:00 typ:11 s(CHS):251/1/193 e(CHS):255/254/255 s:63 l:20980827 [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:33142095 l:16787925 MBREXT Slice 7 on ad0s2: [0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:16787862 [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:49930020 l:2088450 MBREXT Slice 8 on ad0s2: [0] f:00 typ:130 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:2088387 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 MBREXT Slice 5 on ad1s1: [0] f:00 typ:11 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:20980827 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Information from DOS bootblock is: The data for partition 1 is: sysid 11 (0x0b),(DOS or Windows 95 with 32 bit FAT) start 63, size 4208967 (2055 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 261/ head 254/ sector 63 The data for partition 2 is: sysid 15 (0x0f),(Extended DOS (LBA)) start 4209030, size 52018470 (25399 Meg), flag 0 beg: cyl 262/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 139926150, size 16370235 (7993 Meg), flag 0 beg: cyl 1023/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: UNUSED # /dev/ad0s3c: type: ESDI sectors/cylinder: 16065 cylinders: 9729 sectors/unit: 156301488 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 15321596 10485764.2BSD0 0 0 # (Cyl. 65*- 1018*) b: 10485760 swap# (Cyl.0 - 65*) c: 163702350unused0 0 # (Cyl.0 - 1018) Warning, partition c doesn't cover the whole unit! Note that I put the swap partition first. Could that cause this problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Just for Your Information
CARTER Anthony wrote: Hi lads and lassies, I just tried to do a build world that failed, so I tried re-running it and it told me directory not empty (/usr/obj/usr/src/i386*)...Funny, even though the first thing it does is an rm -rf of that directory... So I tried to do it manually (of course as root), but nada. Told me that the directory was not empty (rm -rf telling me THAT???) I can't be certain, but I think I've seen that behavior in the past when I had a corrupt filesystem. Does fsck have anything to say about that partition? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Panic on bootup this morning
After cvsup/rebuild today at about 14:00GMT I now get a 'page fault while in kernel mode' just after the system tries to mount the rootfs. Yesterday's kernel still works fine, and the filesystem came up clean, so I guess the new kernel didn't get far enough to write anything to disk. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Still getting panic on boot.
04:00 GMT Mar 12: Just cvsup'd and rebuilt with same result as 12 hours ago -- I see a kernel panic page fault while in kernel mode just after attempting to mount the root filesystem. The kernel from yesterday works fine and when I reboot the filesystems come up clean, so the new kernel nevers writes to disk, apparently. Am I the only one seeing this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Warning: driver mistake
Starting today I noticed this warning at bootup: WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS Is there more info I should supply? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Warning: driver mistake
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], walt writes: Starting today I noticed this warning at bootup: WARNING: Driver mistake: make_dev(console) called before SI_SUB_DRIVERS Is there more info I should supply? Ooops. No, that is plenty. I'll fix it. Yes, fixed now. Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Another nVidia question, maybe a bit OT.
Because of the repeated breakage of the proprietary nVidia driver in -CURRENT I've been trying out the native XFree86 'nv' driver with some puzzling results. Maybe one of the nVidia whiz-kids in this group can explain: I reboot the machine, then start the X server. The X server immediately aborts with an unresolved symbol vgaHWUnmapMem in nv_drv.o. Okay, so I forgot to load some module in my XF86Config, right? Wrong. All I need to do to is to start X a *second* time and the unresolved symbol error goes away like magic and X starts up. It took me a good while to discover that :-( How the hell does an unresolved symbol get resolved just by retyping the same command? My thought was to look for some kernel module that got loaded in the background, but no. Same kernel modules before and after. And the problem reappears after the next reboot. Any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kernel build - fail
Michael Hostbaek wrote: --ncSAzJYg3Aa9+CRW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I cvsup'ed my source this morning, and after a successfull 'make buildworld' I launch 'make buildkernel KERNCONF=3DGENERIC' - shortly after it dies with the following message: sh /usr/src/sys/kern/genassym.sh genassym.o assym.s perl5 /usr/src/sys/kern/vnode_if.pl -h /usr/src/sys/kern/vnode_if.src vnode_if.pl is a file from the -STABLE tree, not -CURRENT. Which kernel are you trying to build? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvidia module panics today's kernel [03-03-03]
Andre Guibert de Bruet wrote: If you really need to use your workstation, you can try the open source nv XFree86 driver. It's not as fast as the nVidia detonator driver and it's not accelerated, but you can at least use X11 at a reasonable resolution and color depth. It works well enough for my purposes, thanks once again. Actually, I had tried the 'nv' driver once before with no luck, but this time I thought to disable the 'glx' module which is installed by the proprietary nVidia driver and now it works just fine. Maybe I should mention that I'm using a Riva TNT2 chip, not a GeoForce. And, of course, I'm still running my kernel from two days ago, so I'd better try compiling today's kernel before I get too complacent... You've been a great help in the last 24 hours. Thank you! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Disaster strikes...
After cvsup'ing just now I cannot reboot -CURRENT either with the new kernel or the old kernel. The new kernel panics instantly on boot, and the old kernel halts with multiple messages about ACPI, so I'm stuck with an unbootable machine. What is the command to disable acpi at the boot prompt? I tried 'toggle-module acpi' with no luck. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Disaster strikes...
Andre Guibert de Bruet wrote: On Mon, 3 Mar 2003, walt wrote: After cvsup'ing just now I cannot reboot -CURRENT either with the new kernel or the old kernel. The new kernel panics instantly on boot, and the old kernel halts with multiple messages about ACPI, so I'm stuck with an unbootable machine. ...set module_path=/boot/kernel.old at the loader prompt. This will ensure that you're not loading the new modules with your old kernel... Yes! This is exactly what I needed, thank you! The old kernel boots normally now. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
nvidia module panics today's kernel [03-03-03]
My mini 'disaster' of earlier today was caused by the nvidia kernel module being autoloaded at boot, which causes an immediate kernel panic. The newest kernel seems fine until I try to load the module manually, at which time I still get the kernel panic even after re-compiling the module. Maxime, it looks like the nvidia module will need to be sculpted one more time. :-( To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
X server won't start this morning
Just finished a cvsup and rebuild of world/kernel and now my X server refuses to start: (EE) NVIDIA(0): Failed to initialize the NVdriver kernel module! The proprietary nvidia.ko module from nVidia still loads normally with no error messages during system boot. There is also a warning about a 'possible' ulimit on virtual memory available to XFree, but ulimit -a shows no limit on vm, so I'm assuming that is a bogus warning. 'top' shows plenty of unused memory and half a gig of available swap. This was all working perfectly this morning before the cvsup and I've changed nothing in any config files. Anyone else having a similar problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: patch for the nVidia driver and -CURRENT
Maxime Henrion wrote:
--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Hi all,
Recent interface changes made the nVidia driver unbuildable on -CURRENT.
The attached patch should make it work as it used to. Please let me
know if it doesn't.
Yes! Mwa! [Big kiss to Maxime] Thank you!
The only thing I needed to do to make it work was to delete this line
from nv-freebsd.h:
#error This driver does not support FreeBSD 5.0/-CURRENT!
As long as you are patching you may as well patch that one also, yes?
--X1bOJ3K7DJ5YkBrT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=nvidia.patch
diff -u NVIDIA_FreeBSD-1.0-3203/src/nv-freebsd.h nvidia/src/nv-freebsd.h
--- NVIDIA_FreeBSD-1.0-3203/src/nv-freebsd.h Wed Oct 30 15:30:58 2002
+++ nvidia/src/nv-freebsd.h Tue Feb 25 00:00:48 2003
@@ -86,6 +83,7 @@
#if __FreeBSD_version = 50
#include sys/mutex.h
+#include sys/filedesc.h
#include dev/pci/pcireg.h
#include dev/pci/pcivar.h
@@ -306,7 +304,8 @@
intnvidia_open_dev (struct nvidia_softc *);
intnvidia_close_ctl (dev_t, d_thread_t *);
intnvidia_close_dev (struct nvidia_softc *, dev_t, d_thread_t *);
-intnvidia_mmap_dev (struct nvidia_softc *, vm_offset_t);
+intnvidia_mmap_dev (struct nvidia_softc *, vm_offset_t,
+vm_offset_t *);
#endif /* __NV_FREEBSD_H__ */
diff -u NVIDIA_FreeBSD-1.0-3203/src/nvidia_dev.c nvidia/src/nvidia_dev.c
--- NVIDIA_FreeBSD-1.0-3203/src/nvidia_dev.c Wed Oct 30 15:30:58 2002
+++ nvidia/src/nvidia_dev.c Mon Feb 24 23:59:21 2003
@@ -135,6 +135,7 @@
int nvidia_dev_mmap(
dev_t dev,
vm_offset_t offset,
+vm_offset_t *paddr,
int nprot
)
{
@@ -148,7 +149,7 @@
nv = sc-nv_state;
nv_lock_api(nv);
-status = nvidia_mmap_dev(sc, offset);
+status = nvidia_mmap_dev(sc, offset, paddr);
nv_unlock_api(nv);
return status;
diff -u NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c nvidia/src/nvidia_subr.c
--- NVIDIA_FreeBSD-1.0-3203/src/nvidia_subr.c Wed Oct 30 15:30:58 2002
+++ nvidia/src/nvidia_subr.c Tue Feb 25 00:00:14 2003
@@ -1401,7 +1405,8 @@
int nvidia_mmap_dev(
struct nvidia_softc *sc,
-vm_offset_t offset
+vm_offset_t offset,
+vm_offset_t *paddr
)
{
nv_alloc_t *at;
@@ -1412,14 +1417,20 @@
* are physical addresses and mapped into user-space directly. We can
* only do some basic sanity checking here.
*/
-if (IS_FB_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_FB_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
-if (IS_REG_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_REG_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
-if (IS_AGP_OFFSET(nv, offset, PAGE_SIZE))
-return atop(offset);
+if (IS_AGP_OFFSET(nv, offset, PAGE_SIZE)) {
+*paddr = offset;
+return 0;
+}
/*
* If the offset does not fall into any of the relevant apertures, we
@@ -1431,7 +1442,8 @@
SLIST_FOREACH(at, sc-alloc_list, list) {
if (offset = at-address
offset at-address + at-size)
-return atop(vtophys(offset));
+*paddr = vtophys(offset);
+return 0;
}
return -1;
--X1bOJ3K7DJ5YkBrT--
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: NTLDR missing after 5-RELEASE install
Matt Smith wrote: What does your Drive Layout look like? Is your W2k partition FAT32? Has it always been the first partition on the drive, or did you move it, using something like partition magic? Is freeBSD in the extended partition? -Matt On Tue, 2003-02-25 at 11:58, Andrew Boothman wrote: Quoting Lucas Holt [EMAIL PROTECTED]: It probably is. You need to put in the win 2k CD and do a repair on your windows install.. unfortunetely this may screw up your freebsd install. On Tuesday, February 25, 2003, at 05:58 AM, Andrew Boothman wrote: Hi! I've just installed 5-RELEASE, and I asked for the FreeBSD Boot Manager to be installed on both my HDDs. When the machine boots I'm given options for : F1 - DOS F5 - Drive 2 Hitting F5 takes me to a second menu, where I can boot FreeBSD no problem. My problem is that Win2k will no longer boot Hitting F1 displays a message that, NTLDR is missing. I've tried all the repair options on the Win2k setup disc to no avail I think. I'm sorry this isn't directly FreeBSD related, but I really hope my Win2k installation isn't hosed. Thanks for replying! I can't understand how the 5.x boot manager has managed to break my windows boot, i've never had any trouble under 3.x or 4.x, both of which played with windows perfectly nicely. I think i've tried all of the various repair options on the Win2k CD, including getting it to do a fresh installation into a different folder (c:\tempwin), but even that failed with the NTLDR missing message! However you no longer get the booteasy (F1 F2) menu anymore, so Windows must have rewritten something. It still doesn't explain why Win2k still won't boot. My experience with the FBSD boot manager is virtually zero, so I can't address it's workings, but I use GRUB as a booter just because it gets me out of so many jams like yours -- if something isn't where you thought it was you can point GRUB at your disks and let it do the looking for you. The secret is to make a boot floppy with GRUB installed on it. Once you have that there's no machine that's unbootable, and you can reinstall GRUB in seconds if it gets overwritten by Bill Co. For example, IIRC, I just went thru this myself (although it's all so routine now I can't even remember what I do to bail out anymore) when I installed XP on a brand new disk and then installed FBSD afterwards. I got the MBR screwed up just like you, then ran the XP install disk in Repair mode which got XP to boot again but overwrote the FBSD booter. So all I did was boot my trusty GRUB floppy and reinstalled GRUB on the MBR in about 60 seconds and -- done. The next evil news is that I've never really gotten FBSD's incarnation of GRUB to work right for me, so I just install in on the floppy from a linux machine and use that for the FBSD machine. If you have access to GRUB and need instructions I'd be happy to help. Just let me know. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvidia.ko load failed on -current
Jan Stocker wrote: Before blaming me, i know it is not supported for 5.x or -current, but i think some of us have that stuff already running on -current. I've been in hospital for many weeks and now i updated my system (late November) to the currents current. After adding the missing include, i successfully compiled the nvidia driver but loading the kernel module leads to: Feb 24 08:17:08 Twoflower kernel: link_elf: symbol rman_get_start undefined... IIRC I had this same problem when I tried the new scheduler (SCHED_ULE) because (for some reason I don't understand) the linux.ko kernel module was not built when I compiled my kernel. When I went back to the old scheduler (SCHED_4BSD) the linux.ko module reappeared and all worked again -- except that you'll get a 'page fault while in kernel mode' when you shut down the X server. I didn't try actually compiling linux into the kernel with the new scheduler -- you might try that first if you want to run the new scheduler. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvidia.ko load failed on -current
walt wrote: Jan Stocker wrote: Before blaming me, i know it is not supported for 5.x or -current, but i think some of us have that stuff already running on -current. I've been in hospital for many weeks and now i updated my system (late November) to the currents current. After adding the missing include, i successfully compiled the nvidia driver but loading the kernel module leads to: Feb 24 08:17:08 Twoflower kernel: link_elf: symbol rman_get_start undefined... IIRC I had this same problem when I tried the new scheduler (SCHED_ULE) because (for some reason I don't understand) the linux.ko kernel module was not built when I compiled my kernel. When I went back to the old scheduler (SCHED_4BSD) the linux.ko module reappeared and all worked again -- except that you'll get a 'page fault while in kernel mode' when you shut down the X server... Actually, this morning's patch by Scott Long fixed the 'page fault while in kernel mode'. (According to Alfred we'll be seeing file corruption instead, but that's another thread.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Giving up on three buffers...
After this morning's cvsup I now get a 'syncing disks...giving up on three buffers' error message when shutting down the system and the filesystem doesn't get properly dismounted. For the last four days I could never shut the system down cleanly because of the nVidia driver problem causing a kernel panic when X got shut down, so I'm not sure if this problem really just started this morning or somethime in the past four days. Anyone else seeing this just today? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nvidia.ko load failed on -current
Jan Stocker wrote: Jan Stocker wrote: Before blaming me, i know it is not supported for 5.x or -current, but i think some of us have that stuff already running on -current. I've been in hospital for many weeks and now i updated my system (late November) to the currents current. After adding the missing include, i successfully compiled the nvidia driver but loading the kernel module leads to: Feb 24 08:17:08 Twoflower kernel: link_elf: symbol rman_get_start undefined... IIRC I had this same problem when I tried the new scheduler (SCHED_ULE) because (for some reason I don't understand) the linux.ko kernel module was not built when I compiled my kernel. When I went back to the old scheduler (SCHED_4BSD) the linux.ko module reappeared and all worked again -- except that you'll get a 'page fault while in kernel mode' when you shut down the X server. I didn't try actually compiling linux into the kernel with the new scheduler -- you might try that first if you want to run the new scheduler My system has never seen the ULE scheduler, so there must be another thing... I didn't mean to imply that the scheduler itself caused the problem, just that the linux kernel module was missing for some reason and that was really the problem. Are you sure the linux module is there and is loaded before the nvidia kernel module? The link_elf error message suggests that maybe linux is not really there. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Giving up on three buffers...
David Wolfskill wrote: Date: Mon, 24 Feb 2003 07:39:08 -0800 From: walt [EMAIL PROTECTED] After this morning's cvsup I now get a 'syncing disks...giving up on three buffers' error message when shutting down the system and the filesystem doesn't get properly dismounted. For the last four days I could never shut the system down cleanly because of the nVidia driver problem causing a kernel panic when X got shut down, so I'm not sure if this problem really just started this morning or somethime in the past four days. Anyone else seeing this just today? My build machine runs headless, so there may well be a salient difference there, but today's -CURRENT build reboot went just fine... I discovered that I was still running SCHED_ULE from yesterday and switching back to SCHED_4BSD eliminated the problem. I've actually been wondering why the system was so sluggish and now I know why ;-) Compiling a kernel was enough to drag the machine practically to uselessness, but now it's back to it's old self. The new scheduler still needs a bit of tweaking, methinks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel panic on shutdown of X server.
This problem started about Feb 19 and continues thru today's updates. Everything seems to work great until I shut down the X server at which time I get a fatal 'page fault while in kernel mode.' I have two -CURRENT machines at the moment and only the one with the nVidia driver (and kernel module) has the page fault problem. I know the nVidia people don't support the driver for -CURRENT but it has been working perfectly until now, so something important in the kernel changed about four days ago, apparently. Anyone else seeing this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel panic on shutdown of X server.
Terry Lambert wrote: walt wrote: This problem started about Feb 19 and continues thru today's updates. Everything seems to work great until I shut down the X server at which time I get a fatal 'page fault while in kernel mode.' I have two -CURRENT machines at the moment and only the one with the nVidia driver (and kernel module) has the page fault problem. I know the nVidia people don't support the driver for -CURRENT but it has been working perfectly until now, so something important in the kernel changed about four days ago, apparently. Anyone else seeing this? Which scheduler are you using? I have options SCHED_4BSD in my config file. I'll try the other one and see if it changes. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and Extended Slices
Hiten Pandya wrote: On Fri, Feb 07, 2003 at 07:49:54PM -0800, walt wrote the words in effect of: Hiten Pandya wrote: Hi gang. Recently removing the NO_GEOM option from my kernel; I noticed that my dos extended slices dev entries disappeared under a GEOM kernel... I've been using extended slices on both -stable and -current for quite a while without any problems, both with and without GEOM. How were the extended slices created? The extended slices were created before FreeBSD 4.3 was installed on my machine. After that, I just kept building world and kernel and upgraded to 5.0. It used to work before GEOM, but then it suddenly stopped. I just noticed that there are a bunch of GEOM options in /usr/src/sys/conf/GENERIC that I was not using in my custom kernel. I just added several of them that seem at least vaguely appropriate to my machine (I don't know what any of them actually are for, however). Extended slices are still working okay with the new options added. Are you using any of them in your kernel? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and Extended Slices
Hiten Pandya wrote: Hi gang. Recently removing the NO_GEOM option from my kernel; I noticed that my dos extended slices dev entries disappeared under a GEOM kernel... I've been using extended slices on both -stable and -current for quite a while without any problems, both with and without GEOM. How were the extended slices created? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Request for info from SiS chipset owners
Soeren Schmidt wrote: Just reply to this message with the output from pciconf -l and you have helped me sort out the myriads of SiS chipsets out there. ~# pciconf -l chip0@pci0:0:0: class=0x06 card=0x chip=0x55911039 rev=0x02 hdr=0x00 atapci0@pci0:0:1: class=0x010180 card=0x55131039 chip=0x55131039 rev=0xd0 hdr=0x00 isab0@pci0:1:0: class=0x060100 card=0x chip=0x00081039 rev=0x01 hdr=0x00 none0@pci0:1:1: class=0xff card=0x chip=0x00091039 rev=0x00 hdr=0x00 pcib2@pci0:2:0: class=0x060400 card=0x chip=0x00011039 rev=0x00 hdr=0x01 rl0@pci0:11:0: class=0x02 card=0x813910ec chip=0x813910ec rev=0x10 hdr=0x00 none1@pci1:0:0: class=0x03 card=0x63261039 chip=0x63261039 rev=0x0b hdr=0x00 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Installing from CDROM, errors
Damien U wrote: Hello, I will firstly say that although I am not experienced with freeBSD, I have been using Linux for some time. I obtained the first ISO in the set for FreeBSD 5.0-RELEASE last saturday, here are the problems I have been experiencing whilst attempting to install it. 2) Cannot create partition for FreeBSD I can create a slice for freeBSD in fdisk, but it calls the partition X. When I go to commit the changes to hard drive and start the install, freeBSD complains that it cannot find /dev/X. I have found no way to correct the name in fdisk. Here is my partition table as reported by cfdisk under linux: NamePart Type FS Type Size (MB) -- hda1Primary NTFS20974.47 hda2Primary Ext310487.24 hda3Primary Linux Swap 205.64 hda5Logical FAT32 10511.91 hda6Logical Reiserfs10692.87 hda7Logical Reiserfs10001.95 Logical Free Space 17149.71 The BSD family of operating systems must be installed in a 'primary' partition, i.e. those numbered from 1 to 4. More correctly, the root partition / must be in a primary partition -- FreeBSD will happily use a 'logical' partition for any other partition, but not for /. You could copy your ext3 filesystem into a logical partition in free space and then install FBSD in hda2 -- or ad0s2 as FBSD would call it. I understand that this restriction is not theoretically necessary, but just because the bootloader (and perhaps other code) has never been extended to use logical partitions. I would guess that FBSD 4.7 will not even let you attempt to create a partition in the free space, but I can't recall for sure. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Installing from CDROM, errors
walt wrote: Damien U wrote: Hello, I will firstly say that although I am not experienced with freeBSD, I have been using Linux for some time. I obtained the first ISO in the set for FreeBSD 5.0-RELEASE last saturday, here are the problems I have been experiencing whilst attempting to install it. 2) Cannot create partition for FreeBSD I can create a slice for freeBSD in fdisk, but it calls the partition X. When I go to commit the changes to hard drive and start the install, freeBSD complains that it cannot find /dev/X. I have found no way to correct the name in fdisk. Here is my partition table as reported by cfdisk under linux: NamePart Type FS Type Size (MB) -- hda1Primary NTFS20974.47 hda2Primary Ext310487.24 hda3Primary Linux Swap 205.64 hda5Logical FAT32 10511.91 hda6Logical Reiserfs10692.87 hda7Logical Reiserfs10001.95 Logical Free Space 17149.71 The BSD family of operating systems must be installed in a 'primary' partition, i.e. those numbered from 1 to 4. More correctly, the root partition / must be in a primary partition -- FreeBSD will happily use a 'logical' partition for any other partition, but not for /. You could copy your ext3 filesystem into a logical partition in free space and then install FBSD in hda2 -- or ad0s2 as FBSD would call it. Stupid me -- just make an hda8 for your Linux swap partition and use ad0s3 for your FreeBSD install. Nothing to copy that way. Just remember to change the swap entry in your linux /etc/fstab before your next reboot. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel broken at sysv_msg.c
cc1: warnings being treated as errors /usr/src/sys/kern/sysv_msg.c: In function `msgsnd': /usr/src/sys/kern/sysv_msg.c:775: warning: cast discards qualifiers from pointer target type /usr/src/sys/kern/sysv_msg.c:818: warning: cast discards qualifiers from pointer target type *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADSUP: Final call for NODEVFS and NO_GEOM options
Poul-Henning Kamp wrote: This is the final call for users using NODEVFS and NO_GEOM options! I marvel at my own temerity. I normally would never presume to speak for Bruce Evans but I haven't seen a post from him for many days. I think he would probably object to eliminating NO_GEOM based on his past postings. If I presume too much by speaking for him I humbly apologize. BTW, I have no opinion on the subject but I've been using GEOM and DEVFS for quite awhile with no problems that I can detect. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Options MAXMEM added to GENERIC kernel config causes kernel panicin -current
Steve Kargl wrote: On Sun, Jan 26, 2003 at 05:08:40PM -0500, Eric Jones wrote: Is there any reason, on newer motherboards, to need the MAXMEM option? I don't know. I've always used MAXMEM. Guess it's time to remove it from my kernel config file. FWIW, I've been using FBSD -stable and -current for about 3 years on five different machines and I've never used MAXMEM. Never had any problems recognizing memory, either -- guess I've been luckier than some. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
No man page for /etc/malloc.conf ?
Where can I find the definitions for the AJ, aj, HR, etc. that are being discussed in the 'performance' thread? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OpenOffice swriter working on -CURRENT
Sheldon Hearn wrote: Hi folks, Could someone with an up-to-date -CURRENT (as of anything since Wednesday last week) and OpenOffice let me know whether OpenOffice's swriter works? Mine definitely works okay, but I recompiled mine on Jan 14 just after Martin applied some patches. You may get better results if you rebuild OpenOffice. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Plug-n-Pray question
While trying to debug a linux sound driver on my new ASUS A7V8X mobo I changed the Plug-n-Play OS setting from 'no' to 'yes' in the BIOS. When I rebooted the machine back into FreeBSD I got watchdog timer error messages from the Broadcom (bge) ethernet driver and the network was unreachable in spite of the chip being correctly detected and the routing correctly set up. After regaining my composure I finally realized that changing the BIOS setting back was all I needed to do. But it did make me realize that I would not have been able to install FreeBSD on this machine if just by chance that BIOS setting had been on 'yes' when I started out. I never would have figured out why the network wouldn't work right. Makes me wonder how many other mysterious problems might be due to the same thing and if there is something simple that could be done to prevent them? Maybe something as simple as including a warning in sysinstall that the PnP BIOS setting can cause problems? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Geom disklabel/fdisk issues?
[EMAIL PROTECTED] wrote: Julian Elischer writes: I think that one of the things we need to do is declare a new flag in disklabel that declares that the disklabel has been converted to use relative offsets... Better plan: Abandon BSD labels before disks outgrow them. To be replaced bywhat? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
world broken at libkvm
cc -O -pipe -mcpu=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': /usr/src/lib/libkvm/kvm_proc.c:376: structure has no member named `ke_pctcpu' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM prevents bootblocks writing
Sean Kelly wrote: --UlVJffcvxoiEqYs2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 12, 2003 at 12:49:46PM +0100, [EMAIL PROTECTED] wrote: There is an erratum on disklabel -B for 5.0-RELEASE. So how the hell do I make it so I can boot my system again? I don't know what I/it did to make it no longer boot, but I can't. For the short term until the problem is fixed you should be able to edit the disklabel and bootblocks using a floppy fixit disk or the bootable install CD. The problem, IIRC, is that you can't edit a disklabel on a disk with mounted partitions, or somesuch. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_STRATEGY on VCHR?
[EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], walt writes: VOP_STRATEGY on VCHR : 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF), Sorry, need DDB option to print backtrace That feels like an error message (sort of) but everything seems to be working normally. Is this a real problem or just noise? Well, to you it's just noise, to me it's a real problem :-) It is probably the same problem as the one I just commited a fix for. Your patch eliminated my noise -- I hope it also fixed your problem ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nVidia opengl works as root but not as user
David Holm wrote: Hi, it's getting boring seeing all the nvidia posts but I'm so darn close to having it working here... May I ask what you've done to get as far as you have? I have their driver working okay on -STABLE but of course it won't even compile on -CURRENT and I don't know enough to fix it. I'm using their file NVIDIA_FreeBSD-1.0-3203.tar.gz. Are there other sources I could be trying? Other patches? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VOP_STRATEGY on VCHR?
After updating world and kernel this evening I saw this message fly by during the reboot: Mounting root from ufs:/dev/ad0s3a VOP_STRATEGY on VCHR : 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF), Sorry, need DDB option to print backtrace That feels like an error message (sort of) but everything seems to be working normally. Is this a real problem or just noise? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: editting disklabels
Willem Jan Withagen wrote: Hi, I'm trying to edit my disklabels to create some swap on just all of them, however when I try to do so, I get: --- files# disklabel -w -B ad4s1 auto disklabel: ioctl DIOCSDINFO: open partition would move or shrink --- This is in single user mode, with really nothing going on. So I fail to see how that can be true Any references to these kind of problems thus far have to do with GEOM, but this is GENERIC kernel fo 20 dec. No one who knows anything is awake today, so I'll jump in ;-) I just finished editing my partition table and disklabel with the -CURRENT boot/install floppy disks and had no trouble. I think the -CURRENT install CD would do the same, of course. The GEOM code is still changing every day so things are not yet in finished condition. If I understand correctly phk will eventually make it possible to do what you want, but he's not there quite yet. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Trouble building X on fresh 5.0-RC2 install?
I've installed RC2 on my new ASUS A7V8X/AthlonXP and the whole thing went very well except for building XFree. X does compile with no complaints but when I attempt to run it I get unresolved symbol errors and then a coredump. I'm not asking for a fix here, really, so I won't bother you with debugging details. I'm just curious if anyone else has had problems building X recently. I'm a bit reluctant to try re-compiling it on my old stable -CURRENT box because it's working so well ;) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem upgrading to -current
Martin Hasenbein wrote: Hoi, I've tried to upgrade to -current a few minutes ago. Before upgrading I had FreeBSD 4.7-RELEASE-p2 After a make buildworld / make buildkernel /make installkernel and erbooting, I still have FreeBSD 4.7-RELEASE-p2 Sounds like you are rebooting with the old kernel in the / directory instead of the new kernel which is now in the /boot/kernel directory. If you interrupt the boot loader by hitting SPACE, you can then type 'unload' and then 'load /boot/kernel/kernel' then 'boot' which will boot the new kernel. I've never done the upgrade path, so I'm not sure how you are supposed to avoid this problem. Maybe you are doing things in the wrong sequence or skipping steps? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Compile problem again (warnings)
Aleksander Rozman - Andy wrote: Hi ! I am back at developing some stuff for FreeBSD, but I am again getting warnings are treated as errors problem and it seems that -DNO_WERROR doesn't work anymore. Is there a solution for this? I use gcc (Prerelease 3.1). Must I recompile world again? I don't know much about the details but if you're running -CURRENT then you are definitely behind the times. $ gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021119 (release) If your source tree is up to date then you do need to make buildworld again. And probably you would need to rm -rf /usr/include/* before make installworld, to get rid of the obsolete headers. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM panic
[EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Craig Rodrigues writes: Hi, I just did a cvsup and rebuilt my kernel, and now my kernel panics upon bootup. I don't have a serial console, so I wrote down the error messages that I saw: I saw this one in the middle of some GEOM debug statements: ar: FreeBSD check1 failed Can you try this patch please ? Index: geom_mbr.c This patch cured my hang-during-boot problem also. Thanks! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Kernel hangs during boot (new GEOM problem)
walt wrote: I built world+kernel about an hour ago ( Dec 17 about 23:00 UTC) and the kernel hangs in the middle of printing phk's GEOM diagnostics: diagnostics snipped I noticed some GEOM-related commits in today's cvsup, but unfortunately they didn't solve this problem. The kernel still hangs before printing any of the geom diagnostics for the 2nd IDE drive, and responds only to the hard reset button. Meanwhile I'm running with NO_GEOM. I'd be happy to do any diagnostic tests that might be helpful, but I'm new to kernel debugging so I'd need some fairly detailed hints first. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel hangs during boot (new GEOM problem)
I built world+kernel about an hour ago ( Dec 17 about 23:00 UTC) and the kernel hangs in the middle of printing phk's GEOM diagnostics: ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA100 ad2: 42934MB WDC WD450AA-00BAA0 [87233/16/63] at ata1-master UDMA66 acd0: CD-RW R/RW 4x4x24 at ata1-slave PIO4 snip slices 5 to 14 on ad0 MBREXT Slice 15 on ad0s4: 00 01 c1 ff a5 fe ff ff 3f 00 00 00 bd 08 fa 00 |?...| [0] f:00 typ:165 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:16386237 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 This is where the latest kernel hangs--between the first and second IDE disks. When I boot the previous kernel it continues normally with the 2nd disk as follows: MBREXT Slice 5 on ad2s4: 00 01 c1 ff 0b fe ff ff 3f 00 00 00 de 4d 94 00 |?M..| [0] f:00 typ:11 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:9719262 00 00 c1 ff 05 fe ff ff 1d 4e 94 00 bd 86 bb 00 |.N..| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:9719325 l:12289725 MBREXT Slice 6 on ad2s4: 00 01 c1 ff 83 fe ff ff 3f 00 00 00 7e 86 bb 00 |?...~...| [0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:12289662 00 00 c1 ff 05 fe ff ff da d4 4f 01 86 7c fc 00 |..O..|..| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:22009050 l:16546950 MBREXT Slice 7 on ad2s4: 00 01 c1 ff 83 fe ff ff 3f 00 00 00 47 7c fc 00 |?...G|..| [0] f:00 typ:131 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:16546887 00 00 c1 ff 05 fe ff ff 50 a8 04 03 7e 04 7d 00 |P...~.}.| [1] f:00 typ:5 s(CHS):255/0/193 e(CHS):255/254/255 s:50636880 l:8193150 MBREXT Slice 8 on ad2s4: 00 01 c1 ff 07 fe ff ff 3f 00 00 00 3f 04 7d 00 |?...?.}.| [0] f:00 typ:7 s(CHS):255/1/193 e(CHS):255/254/255 s:63 l:8193087 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Mounting root from ufs:/dev/ad0s3a snip # fdisk ad2 *** Working on device /dev/ad2 *** parameters extracted from in-core disklabel are: cylinders=87233 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=87233 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 169 (0xa9),(NetBSD) start 63, size 7373772 (3600 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 458/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 7373835, size 17607240 (8597 Meg), flag 80 (active) beg: cyl 459/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 24981138, size 4112577 (2008 Meg), flag 0 beg: cyl 1023/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: sysid 15 (0x0f),(Extended DOS (LBA)) start 29093715, size 58830030 (28725 Meg), flag 0 beg: cyl 1023/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 80386 out of GENERIC
[EMAIL PROTECTED] wrote: Because few if any 80386 computers have the ram it takes to run sysinstall. Was sysinstall around when 386 was new? Just curious what's changed since then to make it bigger. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Sound familiar? 5.0-RC hangs on dual athlon
Jacques A. Vidrine wrote: Hello All, I finally managed to put some time aside to redo my main development/desktop machine to run FreeBSD 5.0. (I've been running 5.x on my laptop for some months.) I had to retreat back to 4.7 because I could not get through some simple tasks without the system hanging. The system is a dual Athlon box with 1 GB RAM. The dmesg output is below. At first the system hung while I was building GNOME 2.0 and restoring some files from tape. It wasn't _completely_ hung: I could switch VTYs, and enter new commands (though it might take tens of seconds to echo my typing... I seem to remember something similar from a few months ago that affected machines with lots of RAM because of something to do with high order address bits. I thought it got fixed, but I can't really recall. Was it an Athlon problem, or a gcc problem, or both? Hmpf, can't remember! Anyone else think this might be the same thing? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to UFS2 Superblock Format
Poul-Henning Kamp wrote: From the next branch on -current, it is my intent to not install BSD labels anymore, but switch to GPT instead, (possibly encapsulated in an BSD MBR slice for legacy systems). Do you mean this GPT: http://www.microsoft.com/hwdev/tech/storage/GPT_FAQ.asp or are you speaking of something else? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
buildkernel broken at bluetooth?
mkdep -f .depend -a -nostdinc -I../../../../netgraph/bluetooth/include -D_KERNEL
-DKLD_MODULE -I- -I../../../../netgraph/bluetooth/include -I. -I@ -I@/dev -I@/../include
-I/usr/obj/usr/local/mnt/src/i386/usr/include
/usr/local/mnt/src/sys/modules/netgraph/bluetooth/bluetooth/../../../../netgraph/bluetooth/common/ng_bluetooth.c
/usr/local/mnt/src/sys/netgraph/bluetooth/common/ng_bluetooth.c:38:26: ng_bluetooth.h:
No such file or directory
mkdep: compile failed
My /usr/src is a symlink to another partition which is mounted
on /usr/local/mnt/src. I can make it compile by modifying the
Makefiles in sys/modules/netgraph/bluetooth like this:
CFLAGS+= -I${.CURDIR}/../../../../netgraph/bluetooth/include
Maybe there's a better way to do this?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
make buildkernel broken at net/bpf.c ?
I see these changes were made about four days ago and I seem to be the only one having problems. BTW, I don't use device bpf in my kernel config. cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -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-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/net/bpf.c /usr/src/sys/net/bpf.c: In function `bpf_tap': /usr/src/sys/net/bpf.c:1419: argument `ifp' doesn't match prototype /usr/src/sys/net/bpf.h:345: prototype declaration /usr/src/sys/net/bpf.c: In function `bpf_mtap': /usr/src/sys/net/bpf.c:1426: argument `ifp' doesn't match prototype /usr/src/sys/net/bpf.h:346: prototype declaration *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kernel won't build without 'device bpf'
Buildkernel dies without device bpf in the config file. I think this is due to Sam's commit on 11-14 changing sys/net/bpf.c and bpf.h. Anyone else seeing this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Make world as benchmark?
I have two identical installations of -CURRENT on one machine. The only difference is that one is on a UDMA100 disk and the other is on a UDMA66 disk. Both have softupdates enabled. The total times for a make world make kernel: UDMA100: 88 minutes UDMA66 : 95 minutes Does this seem an appropriate difference? Anyone else tried the same thing? Next I'll disable softupdates and repeat the test. Any predictions on how much difference I'll see? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree
Horen wrote: Posted a week ago the question, didn't get any reaction. Everything with current from last night works fine but killing X or logging out ends in a black screen. No way to activate the display without reboot. Remote login is fine. Typing blind works too. I have exactly the same problem on my NetBSD box but I haven't spent any time trying to fix it. I wonder if the console font color is being reset to black. You could try typing 'vidcontrol white black' to test that theory. Dunno what might be causing it, though. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
Hiten Pandya wrote: Hmm, OK. Let me rephrase it all. I have a 120G IDE disk, which is under LBA mode. It is the second disk on my system. I have been using it with my old (julyish) -current for a while now as a backup disk thingy. My disk layout: ad1s1: 8997MB FreeBSD slice ad1s3: 50995MB FreeBSD slice ad1s2: 54478MB FAT32 slice Here you are discussing ad1, which should (I think) be the slave drive on the first IDE controller. This is how Sysinstall's fdisk reports it in 5.0-CURRENT-20021028. The sizes are displayed correctly here, but when I try labeling the disk through sysinstall's Configure-Label, It shows: Disk: ad3 Partition name: ad3s1 Free: 0 blocks (0MB) Disk: ad3 Partition name: ad3s3 Free: 102110549 blocks (49858MB) Here you are discussing ad3, which should be the slave drive on the *second* IDE controller. Are you intending to discuss two different physical disks here? I'm still a bit confused. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
Hiten Pandya wrote: On Sat, Nov 02, 2002 at 10:38:33AM -0800, walt wrote the words in effect of: Hiten Pandya wrote: Hmm, OK. Let me rephrase it all. I have a 120G IDE disk, which is under LBA mode. It is the second disk on my system. I have been using it with my old (julyish) -current for a while now as a backup disk thingy. My disk layout: ad1s1: 8997MB FreeBSD slice ad1s3: 50995MB FreeBSD slice ad1s2: 54478MB FAT32 slice Here you are discussing ad1, which should (I think) be the slave drive on the first IDE controller. This is how Sysinstall's fdisk reports it in 5.0-CURRENT-20021028. The sizes are displayed correctly here, but when I try labeling the disk through sysinstall's Configure-Label, It shows: Disk: ad3 Partition name: ad3s1 Free: 0 blocks (0MB) Disk: ad3 Partition name: ad3s3 Free: 102110549 blocks (49858MB) Here you are discussing ad3, which should be the slave drive on the *second* IDE controller. Are you intending to discuss two different physical disks here? I'm still Oops, change that ad3 into ad1. Okay. Well, I see that just today sysinstall/label.c was updated to correct an error. I have no idea if that may be your problem, but errors do creep in regularly into -CURRENT, so it's possible. My gut feeling is that your files are still there ready to be used but probably not with the system you are using now. I would download a -STABLE installation floppy from the FBSD ftp site and see if you can use that disklable editor to examine the disk. If the disklabel looks correct then you can proceed to install a -STABLE system on that disk using the *existing* label, and your data should be intact. If the disklabel still looks bad then you have a bigger problem. You really need to save every label somewhere and restore it later if it gets trashed. I just use a pencil and paper and write it all down and tape the paper to the computer--very primitive but it's saved my backside more than once ;-) When fooling with -CURRENT you need to be ready for such disasters, and often all it takes is a pencil and paper and five minutes of preparation. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Unsucessful with 5.0-CURRENT Installation on a 120G IDE HDD
Hiten Pandya wrote: Hi there. I tried installing the 5.0-CURRENT-20021028-JPSNAP ISO today, on my 120G harddrive, which is the second one on the system. Sysinstall failed to get the right geometry of the disk, even though the BIOS was in LBA mode. My 50G FreeBSD partition (ad1s3) as two partitions, 1000MB and a 128MB. Sorry, I'm not understanding that sentence. Is there a typographical error in there somewhere, perhaps? 1000MB + 128MB 50GB The DOS partition (ad1s2) on the harddrive was just right, and nothing wrong it, but only the FreeBSD partitions messed up. Sorry, I'm still confused. You have two different FBSD partitions on the same disk (s3 and s1)? I made a 8G partition on the front of the disk (ad1s1), in which I was planning to install FreeBSD. Now, I am not sure what the real cause is, i.e. why are we not allowed to install on an 8G partition on a 120G disk? No reason. It should work. Is the install failing at some point with error messages? Did the install finish but now you can't boot the new system? It could be that I am doing something very wrong, but I would like to get to the bottom of this, as I lost about 15G worth of data, I'm confused again. Data on the FreeBSD partition? Which FBSD partition? How did the data get there and in what way is it lost now, exactly? i.e. fdisk still shows that the partition is there, but fsck_ffs is not proceeding. You mean when you try to boot the 8GB partition, or the 50GB partition? Is fsck complaining about something? What is it saying? Please be very specific about error messages. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current buildworld breakage
Yamada Ken Takeshi wrote:
I have an error for a week and cannot make buildworld.
Where can I find panic other than real panic?
=== sbin/gbde
: : : :
cc -O -pipe -mcpu=pentiumpro -I/usr/src/sbin/gbde/../../sys -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c template.c
cc1: warnings being treated as errors
/usr/src/sys/crypto/rijndael/rijndael-api-fst.c: In function `rijndael_padEncrypt':
/usr/src/sys/crypto/rijndael/rijndael-api-fst.c:222: warning: implicit declaration of function `panic'
*** Error code 1
This is taken from my rijndael-api-fst.c:
for (i = numBlocks; i 0; i--) {
rijndaelEncrypt(input, outBuffer, key-keySched, key-ROUNDS);
input += 16; /* this is line 222 */
outBuffer += 1;
}
I can't see how line 222 includes an implicit declaration of 'panic'.
Is your file different?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
emacs?
I'm confused about the -CURRENT emacs breakage. Is this an O.S. breakage which will eventually be fixed, or a permanent change which will require a patch to emacs? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
Alexander Kabaev wrote: On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage... ...The code in [x]emacs is not prepared to deal with the change in format and thus will have to be fixed, or the while issue could be worked around by linking [x]emacs binary with -znocombreloc. Hmm. I tried make LDFLAGS=-znocombreloc but that doesn't fix the crashes. Am I doing the wrong thing? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs?
John Baldwin wrote: On 22-Oct-2002 walt wrote: Alexander Kabaev wrote: On Tue, 22 Oct 2002 11:08:29 -0700 walt [EMAIL PROTECTED] wrote: I'm confused about the -CURRENT emacs breakage... ...could be worked around by linking [x]emacs binary with -znocombreloc. Hmm. I tried make LDFLAGS=-znocombreloc but that doesn't fix the crashes. Try LDFLAGS=-Wl,-znocombreloc, that's what I used to get xemacs working. Yes, that worked, thanks. I found I had to edit the generated Makefile in /usr/ports/editors/emacs20/work/emacs-20.7 because 'configure' complained about the LDFLAGS, otherwise. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
open-motif compilation problem
While compiling the open-motif port on -CURRENT I see this
error during the 'configure' phase. Anyone else seeing this?
checking for vprintf... yes
checking whether sprintf returns void... Bus error (core dumped)
yes
checking for wcslen... yes
===
This seems to be the code that causes the error:
===
echo $ac_n checking whether sprintf returns void... $ac_c 16
echo configure:8121: checking whether sprintf returns void 5
if eval test \`echo '$''{'ac_cv_func_void_sprintf'+set}'`\ = set; then
echo $ac_n (cached) $ac_c 16
else
if test $cross_compiling = yes; then
ac_cv_func_void_sprintf=yes
else
cat conftest.$ac_ext EOF
#line 8129 configure
#include confdefs.h
#include stdio.h
int sprintf(); main() { exit(sprintf(.)); }
EOF
if { (eval echo configure:8134: \$ac_link\) 15; (eval $ac_link) 25; } test -s
conftest${ac_exeext} (./conftest; exit) 2/dev/null
then
ac_cv_func_void_sprintf=no
else
echo configure: failed program was: 5
cat conftest.$ac_ext 5
rm -fr conftest*
ac_cv_func_void_sprintf=yes
fi
rm -fr conftest*
fi
fi
echo $ac_t$ac_cv_func_void_sprintf 16
if test $ac_cv_func_void_sprintf = no; then
cat confdefs.h \EOF
#define VOID_SPRINTF 1
EOF
fi
=
From config.log:
=
configure:8121: checking whether sprintf returns void
configure:8134: cc -o conftest -O -pipe -mcpu=pentiumpro -DCSRG_BASED -DXUSE_MTSAFE_API
-DXNO_MTSAFE_PWDAPI conftest.c 15
configure: failed program was:
#line 8129 configure
#include confdefs.h
#include stdio.h
int sprintf(); main() { exit(sprintf(.)); }
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
emacs problems?
I'm having problems with emacs 20.7 running under X: #emacs Fatal error (11).Segmentation fault (core dumped) but emacs -nw works fine (i.e. without X). This started after doing a portupgrade -fa to solve the _sF symbol problem. I've recompiled every package that emacs depends on and still no change. The backtrace isn't very helpful. I suppose I need to build emacs with debugging enabled? Any hints how to do that? Anyone else seeing this problem? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM question
Bruce Evans wrote: Don't use extended partitions directly. It is easy to make a mess by clobbering the pointers to the logical drive within them. I need to ask for clarification on this point. What do you mean by 'directly'? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM question
Bruce Evans wrote: On Wed, 16 Oct 2002, walt wrote: Bruce Evans wrote: Don't use extended partitions directly. It is easy to make a mess by clobbering the pointers to the logical drive within them. I need to ask for clarification on this point. What do you mean by 'directly'? Just write to them using anything that doesn't understand that they are containers for logical drives. E.g., newfs would leave their boot record intact since it leaves some sectors for the label and boot blocks, but it would scribble over any logical drives within the extended partition in a non-useful way. Once again you leave me puzzled. 'newfs /dev/ad2s8' is exactly how I formatted the partition and everything is working perfectly. I went back and checked the other four filsystems in that extended partition and none of them have errors. (Two fat32, one ext2, one NTFS.) In addition I see this on -CURRENT (with GEOM): #disklabel ad2s8 disklabel: ioctl DIOCGDINFO: Operation not supported by device and this on -STABLE (different machine): # disklabel ad0s7 disklabel: ioctl DIOCGDINFO: Invalid argument so (for me) disklabel does not work on extended/logical partitions. I'm wondering if something major has changed in the years since you last tried using logical drives in FreeBSD? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM question
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], walt writes: Would the GEOM framework make it feasible to use a DOS-extended/logical partition for a BSD filesystem? We already support that as far as I know, both with and without GEOM Yes! The reason I could never make it work is because of an 'error' in the man page for newfs: Before running newfs the disk must be labeled using disklabel(8) Well, disklabel won't work on an extended/logical partition so I never actually got as far as newfs until just now. Turns out that newfs works just great without a disklabel on a logical partition. I just moved the entire ports collection to my brand new 8Gb ufs partition and never went near growfs. I'm very happy! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM question
[EMAIL PROTECTED] (Bruce Evans) writes: On Tue, 15 Oct 2002, walt wrote: Well, disklabel won't work on an extended/logical partition... Um, disklabel works on any slice. E.g.: ttyv1:root@gamplex:/tmp disklabel ad2s3 #size offsetfstype [fsize bsize bps/cpg] c: 10281600unused0 0 # (Cyl.0 - 1019) We have a semantic problem, as often happens when the DOS and BSD worlds collide. s3 is a 'slice' which is the same as a 'DOS primary partition' and yes, disklabel works on any 'primary' partition. My new BSD filesystem is on ad2s8, which is a DOS 'logical' partition in my 'DOS-extended' (primary) partition ad2s4: #fdisk ad2 The data for partition 4 is: sysid 15 (0x0f),(Extended DOS (LBA)) The logical drive is numbered 's8' because it is the 4th 'logical' drive in the 'extended DOS' slice, and the 'logical' drives are numbered beginning with s5 and work upwards from there, and they don't show up in FBSD's fdisk, unfortunately, though they do show up in /dev. The 'primary' partitions are numbered 1 thru 4 only. I think we have M$ (and perhaps IBM) to thank for this marvelous feature of the PC which has caused so many headaches over the decades. If there is a way to create 'logical' partitions in FreeBSD I'm not aware of it. I usually use PartitionMagic to do all the grunt work of creating and resizing such partitions. And now I can use them as native BSD ufs filesystems, which I never knew until now. Cool! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
GEOM question
Would the GEOM framework make it feasible to use a DOS-extended/logical partition for a BSD filesystem? This would add a great deal of flexibility for adding disk space to a full filesystem, just as one example. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and NetBSD partitions/disklabels
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Jens Schweikhardt writes: Poul-Henning et al, recently I've tried installing NetBSD on a new disk. I'm not sure if the following is a coincidence (because it never worked before, even without GEOM) or is due to GEOM issues. My -current is from Oct 12 and the kernel derived from GENERIC, plus/minus devices/options to match my hardware. NetBSD uses sysid 169 for their slice and a new style disklabel with 16 partitions. FreeBSD is unable to deal with that disklabel, it seems. We never had to ability to do this before. GEOM can probably do it for you, with something like this patch: snip Oops. Now I get the same error with both kinds of partitions: disklabel: ioctl DIOCGDINFO: Operation not supported by device (However, it compiled just fine ;-) I have a NetBSD partition I'd like to read also. Is there something simple, or preferably even braindead, that I can do to debug this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM and NetBSD partitions/disklabels
BOUWSMA Beery wrote: ...That is, your kernel can mount the NetBSD partitions with their 16 partitions within, even if `disklabel' doesn't work yet... Heh, I just mounted the NBSD partition using an un-patched FBSD kernel with GEOM, even though disklabel (recompiled) refuses to list it. Here's what I see: #l /mnt ls: altroot: Bad file descriptor ls: bsd: Bad file descriptor ls: bsd.old: Bad file descriptor ls: dev: Bad file descriptor ls: fbsd: Bad file descriptor ls: mnt: Bad file descriptor ls: usr: Bad file descriptor ls: var: Value too large to be stored in data type total 1498363071 drwxr-xr-x 16 rootwheel 512 Aug 4 2001 ./ drwxr-xr-x 23 rootwheel 512 Oct 13 16:18 ../ -rw-r--r-- 2 rootwheel 669 Apr 28 2001 .cshrc -rw-r--r-- 2 rootwheel 148 Apr 28 2001 .profile -rw-r--r-- 1 rootwheel 3947412 Jul 25 2001 GENERIC dr-x-w--wt 18770 rootwheel 3473181757988490561 Oct 4 2013 bin/ -r-xr-xr-x 1 rootwheel53248 Jul 25 2001 boot* drwxr-xr-x 2 rootwheel 512 Jul 25 2001 cdrom/ c--Sr-xrwt 9248 1348826468 544437612 109, 0x69740062 Dec 8 2023 etc* cr-Sr-srwt 9248 544175136 744846197 120, 0x726f0020 Sep 6 1996 home* dr-xrwsrwx 17996 10451783648768 0 Dec 31 1969 root/ br-sr-sr-T 24930 1634890872 1931506787 32, 0x20200020 Jan 29 1987 sbin* d--Srwxr-- 19796 1801675106 1970238055 2314861471017813320 Nov 4 2006 stand/ lrwxr-xr-x 1 rootwheel 11 Jul 25 2001 sys@ - usr/src/sys br--rT 28015 1886718585 544175136 108, 0x2079006e Nov 14 2022 tmp What a mess. I hope I can un-bork any damage I may have done. (I have no problem mounting rw when needed; note that you also will need to modify NetBSD's fsck as needed to be done in FreeBSD-stable or use an alternate superblock under NetBSD after a FreeBSD rw mount... Thanks for the reminder. I'd completely forgotten about that problem. Now I'll go and re-apply phk's patch (which was undone by cvsup) and try again. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Buildworld broken at gdb?
Following the gcc/binutils update: arch-utils.o(.data+0x40): undefined reference to `bfd_elf32_i386_vec' *** Error code 1 Stop in /usr/src/gnu/usr.bin/binutils/gdb. Anyone else seeing this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Big bezier ramblings
I trotted out xfontsel to use as a sharp stick to poke at this bug. I certainly succeeded at crashing the X server with it repeatedly, but the crashes are non-deterministic. The same choice of font and fontsize will not reliably crash each time. The wierd thing I did find is that, after crashing the X server and then restarting it, I would find anywhere up to six instances of xfontsel on the desktop instead of just one. (Using gnome2, FWIW.) Dunno what that means, but maybe someone else can use it as a clue? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: i386 tinderbox failure
=== usr.bin/truss syscalls.master: line 34: syscall number out of sync at 0 I see this too. The last time it was broken awk (IIRC) that was responsible, though it doesn't seem likely this time. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: GEOM problems?
Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], walt writes: #disklabel ad0 disklabel: ioctl DIOCGDINFO: Operation not supported by device ad0 does not have a disklabel. Okay, next problem(?). Disklabel with and without the -r flag: #disklabel -r ad2s2 #size offsetfstype [fsize bsize bps/cpg] a: 17207240 77738354.2BSD0 0 0 # (Cyl. 483*- 1554*) b: 40 7373835 swap # (Cyl. 459 - 483*) c: 17607240 7373835unused0 0# (Cyl. 459 - 1554) Warning, partition c doesn't start at 0! Warning, partition c doesn't cover the whole unit! Warning, An incorrect partition c may cause problems for standard system utilities Warning, partition d: size 0, but offset 7373835 Warning, partition e: size 0, but offset 7373835 Warning, partition f: size 0, but offset 7373835 Warning, partition g: size 0, but offset 7373835 Warning, partition h: size 0, but offset 7373835 #disklabel ad2s2 #size offsetfstype [fsize bsize bps/cpg] a: 17207240 404.2BSD0 0 0 # (Cyl. 24*- 1095*) b: 400 swap # (Cyl.0 - 24*) c: 176072400unused0 0# (Cyl.0 - 1095) Warning, partition c doesn't cover the whole unit! This behavior is new with GEOM, as is the warning about c not covering the whole unit. The kernel without GEOM offers no complaints about the same label. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdlib.h:57: redeclaration of C++ built-in type `wchar_t'
Hanspeter Roth wrote: Hello, when running buildworld I get: === gnu/usr.bin/gperf/doc c++ -O -pipe-D__FBSDID=__RCSID -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/contrib/gperf/src/bool-array.cc c++ -O -pipe-D__FBSDID=__RCSID -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/usr/src/gnu/usr.bin/gperf -c /usr/src/contrib/gperf/src/gen-perf.cc In file included from /usr/src/contrib/gperf/src/gen-perf.cc:23: /usr/include/stdlib.h:57: redeclaration of C++ built-in type `wchar_t' *** Error code 1 #ifdef _BSD_SIZE_T_ typedef _BSD_SIZE_T_size_t; #undef _BSD_SIZE_T_ How can I resolve this redeclaration? I'm no expert, but I'd guess you have some stale header files in /usr/include. You could try this: cd /usr mv include include.old cd /usr/src make includes make buildworld There may be things in the include.old directory you would want to move back to /usr/include [1], so I would look through it before deleting the whole thing. If you want to be more conservative you could just start by moving /usr/include/g++ out of the way instead of the whole /usr/include, but that may or may not be sufficient. [1] I'm not sure this applies to FreeBSD, since the ports are supposed to put their header files in /usr/local/include, but I don't want to give you risky advice when I'm not certain. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
