Re: handling pdfs?
Atom Smasher wrote: On Wed, 28 Nov 2007, Wilkinson, Alex wrote: /usr/ports/print/pdftk/ that's a good first choice, but if it doesn't work (amd64) then a second choice is print/pdfjam and/or print/psutils-(letter|a4)... and ghostscript for pdf2ps and/or ps2pdf... but yeah, pdftk is best if it works for you. Thanks, everyone, appreciate that. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux executable picks up FreeBSD library over linux one and breaks
Yuri wrote: I am trying to run Linux version of Skype and am getting the following error: /usr/home/yuri/skype/current/skype: error while loading shared libraries: /usr/lib/librt.so.1: ELF file OS ABI File /usr/lib/librt.so.1 is FreeBSD library and /usr/compat/linux/lib/librt.so.1 is Linux library with the same name installed by linux_base-fc-4_10. My LD_LIBRARY_PATH is set to /usr/compat/linux/lib:/usr/compat/linux/usr/lib. Why FreeBSD version is being picked up even though it's not in LD_LIBRARY_PATH? You've gotten some good suggestions, but I might add one more, I don't think it's been mentioned. I have foound, myself in the last 2 weeks, some FreeBSD ports putting in Linux tools, installing stuff in the wrong places, like sticking in SYSV libraries in /usr/local/lib instead of /compat/linux/usr/lib. I verified in that case that the Linux ldconfig didn't find the library, before I manually moved the library to the /compat path, and reran the linux ldconfig. I can't remember, for sure right now, which port it was, but I think it was a Linux browser. I remember the action, and that moving the libs (several different ones) did fix the problem. If you can't find the lirary using the Linux ldconfig (and remember that it uses different parameters to search with), then you need to find where the libs are actually stuck, and make sure the place makes sense. Sticking SYSV libs into a directory full of BSD libs doesn't make thje best sense, I think. But I could be wrong on that, I haven't yet got enough experience with the Linux emulation to make certain. This seems to me sense with what I read in the handbook regarding the Linux emulation. Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: handling pdfs?
Gary Jennejohn wrote: On Wed, 28 Nov 2007 13:05:18 -0500 Bill Moran <[EMAIL PROTECTED]> wrote: In response to Giorgos Keramidas <[EMAIL PROTECTED]>: On 2007-11-27 21:27, Chuck Robey <[EMAIL PROTECTED]> wrote: I need to read about 4 tons of some really sparse pdf specs. I also have a rather inconvenient throwback: I feel hugely more at home-reading documents in paper. What I'd kind of like to do would be able to perform cut'n'paste among different pdfs, 5 pages here, 10 pages there, until I put together maybe 100-200 pages, and sit back and read it. What I can't do is print just a few pages out of several 800-plus page specs, and perform paper cut'n'pasting. If you find a way to 'save' only parts of a PDF document, i.e. pages 5-10, 17 and 25 in a separate file, then the ``pdfjam'' port includes a utility called ``pdfjoin'' :) You could print the desired pages to .ps files, use ps2pdf to convert them and then pdfjam to combine them. It's enough of a roundabout that I don't know if it's worth it or not. xpdf allows printing of page ranges. I use it all the time. I'm not sure why, maybe I have too poor a font selection here, but the fonts, I mean, the onscreen fonts that xpdf seems to choose, always seems to run characters together, so it gets hard to read them. So, xpdf wouldn't be my first choice. I use kpdf to view pdfs for that particular reason, and onthe same document, kpdf does a distinctly better job, If kpdf uses xpdf's engine, then it must find some way to pick better fonts for itself, it actually does look better. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: handling pdfs?
Julian H. Stacey wrote: Giorgos Keramidas wrote: On 2007-11-27 21:27, Chuck Robey <[EMAIL PROTECTED]> wrote: I need to read about 4 tons of some really sparse pdf specs. I also have a rather inconvenient throwback: I feel hugely more at home-reading documents in paper. What I'd kind of like to do would be able to perform cut'n'paste among different pdfs, 5 pages here, 10 pages there, until I put together maybe 100-200 pages, and sit back and read it. What I can't do is print just a few pages out of several 800-plus page specs, and perform paper cut'n'pasting. If you find a way to 'save' only parts of a PDF document, i.e. pages 5-10, 17 and 25 in a separate file, then the ``pdfjam'' port includes a utility called ``pdfjoin'' :) /usr/local/bin/pdf2ps # ghostscript-gnu-7.07_15/+CONTENTS:bin/pdf2ps then gs allows printing of page numbers then print PS or /usr/local/bin/ps2pdf # /usr/ports/print/ghostscript-gnu Seeing as I start out with pdfs here, yo probably meant pdf2ps, not ps2pdf, right? I will take another look at this, but in the past, when I have tried to use pdf2ps, it often would yield me pstscripts that couldn't be pages, for some reason. Maybe that's an old, fixed bug? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: handling pdfs?
Ulrich Spoerlein wrote: On Tue, 27.11.2007 at 21:27:41 -0500, Chuck Robey wrote: Is there some sort of util that will allow me to do cut'n'pasting among different pdfs, or at the very least, only to print certain ranges out of pdf docs, so I could do paper-wise cut'n'paste? An all-electronic solution would be best, but I'd take whatever offered. Lots of tools have already been mentioned. I'll just throw in pdflatex+pdfpages. You can easily zoom, rotate and N'up pages of different PDF files. I'm happily buried underneath some prertty good sugestions, and one by one, I'll be trying them all, thanks. Cheers, Ulrich Spoerlein ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux executable picks up FreeBSD library over linux one and breaks
Alexander Leidinger wrote: Quoting Chuck Robey <[EMAIL PROTECTED]> (from Sun, 02 Dec 2007 13:23:33 -0500): You've gotten some good suggestions, but I might add one more, I don't think it's been mentioned. I have foound, myself in the last 2 weeks, some FreeBSD ports putting in Linux tools, installing stuff in the wrong places, like sticking in SYSV libraries in /usr/local/lib instead of /compat/linux/usr/lib. I verified in that case that the Linux If they put the libs directly in /usr/local/lib instead of /usr/local/lib/, then it is a big error. But if it is in a subdirectory where no FreeBSD lib resides, it is ok (the linux browser sets LD_LIBRARY_PATH in the start script to the right path). Have a look how the native browser works, the private libs are not in ldconfig either and the browser start script sets the library path for the browser binary. At least it did this the last time I checked... Does that mean that all programs needing those libs must have wrapper shells, so as ot implement the LD_LIBRARY_PATH? I know of programs that bomb if that's even set at all, and I think it can be a security tool, and I just think that there is no good reason for installing Linux libs outside of the compat tree. There isn't any good reason not to use the compat tree, is there? You know, there's a local there too, so you don't even need to be ignoring LOCALBASE, which is something I don't care for ports to do at all. I just don't see any reason for such a obviously pathological thing to occur. Just because it's possible to fix it, program by program, by implementing wrapper scripts, you aren't going to tell me that's some sort of elegant fix, so the fact that doing such a thing is justified? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel config for networking
I've been having problems trying to get the onboard networking to work with this Asus Striker Extreme ever since I first put FreeBSD-current on it. Right now, I have a cheapy junk-pile card that probes as a dc0 working, but my motherboard has two nfe's (nfe0 & nfe1) that show up on the desmg. If I use ifconfig and activate them, the whole machine comes to a complete halt (complete, neither console nor ssh sessions work, machine is dead to the world apparently) and this starts whenever I use ifconfig to turn up either nfe0 or nfe1. I've complained before, but a new possibility occurred to me, while I was slowly reading the NOTES in /sys/i386/conf, that the networking stuff is very sensitive to order. Is that still true? If I have a dc device and a nfe device, do I need to be aware of anything as regards the config file statement order? Thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux executable picks up FreeBSD library over linux one and breaks
Alexander Leidinger wrote: Quoting Chuck Robey <[EMAIL PROTECTED]> (from Mon, 03 Dec 2007 13:30:50 -0500): Alexander Leidinger wrote: Quoting Chuck Robey <[EMAIL PROTECTED]> (from Sun, 02 Dec 2007 13:23:33 -0500): You've gotten some good suggestions, but I might add one more, I don't think it's been mentioned. I have foound, myself in the last 2 weeks, some FreeBSD ports putting in Linux tools, installing stuff in the wrong places, like sticking in SYSV libraries in /usr/local/lib instead of /compat/linux/usr/lib. I verified in that case that the Linux If they put the libs directly in /usr/local/lib instead of /usr/local/lib/, then it is a big error. But if it is in a subdirectory where no FreeBSD lib resides, it is ok (the linux browser sets LD_LIBRARY_PATH in the start script to the right path). Have a look how the native browser works, the private libs are not in ldconfig either and the browser start script sets the library path for the browser binary. At least it did this the last time I checked... Does that mean that all programs needing those libs must have wrapper shells, so as ot implement the LD_LIBRARY_PATH? I know of programs Yes. For the mozilla stuff it seems to be a design decision of them to put the libs in a non-standard path (this is independent from the OS). Don't shoot FreeBSD, shoot them if you don't like this. that bomb if that's even set at all, and I think it can be a security tool, and I just think that there is no good reason for installing Linux libs outside of the compat tree. There isn't any good reason not You have 2 differet issue here. One issue is that some program(-suites) decide to put their libs into a non-standard directory. The other one is that you should not mix libs from linux and FreeBSD. to use the compat tree, is there? You know, there's a local there too, so you don't even need to be ignoring LOCALBASE, which is something I don't care for ports to do at all. > > Even if you have them in LINUXBASE, you could pick up the wrong libs > depending on the search order of the libs directories and the location > of the libs. > > The big goal is, that an user should not have the need to put > /compat/linux/... into his path to start a linux program. We can do this > by putting those linux programs into LOCALBASE (easy, if they don't > install libs or hide the libs in special dirs), or by putting them into > LINUXBASE and add a wrapper script to LOCALBASE (not as easy, as you > have to have more knowledge about pkg-plist in the ports to get the port > to do the right thing). You have jumped over the issue I wanted to address, at least, it looks like that to me. It seems like you are telling me why Linux libs need to be in different dirs, but I did say I understood that. You really do need to have them in different directories, so that the two different file types can more easily be administered both by users and by ldconfig. I am not arguing that, not for an instant, so please read this following text. I am complaining about mixing FreeBSD and non-FreeBSD libs, both of them in the /usr/local tree. I know that it can do this, but I am saying that this is an unnecessary complication, and that all Linux binaries and libraries, etc. should actually go into the /compat/linux tree instead. As far as possible, our ports tree should not contribute to the confusion. There are a large host of reasons why this is so, even some beyond the obvious 2, of needing to help users keep the separation, and to make keeping the ldconfig stuff separate. There is also an ugly trend in most linuxes to install everything into /usr, and not to have any /usr/local at all. This is very easily accomodated with /compat/linux, but it's a major PITA if Linux stuff must go into /usr/local. Trying to get the Linux software to give up this silly bias isn't even an issue, if it was installed into /compat/linux. I really like the ability to have different apps, ones that really do fall in different categories, to install in different areas. Among other things, this allows one to very easily do a chroot in /compat/linux. I have tried it, it really works fine, and lets you have a really good level of Linux compatibility. We lose that totally if the Linux and FreeBSD stuff is mixed with a different subdir for eacy lousy app. Let me illustrate this further. A whole lot of apps take this tack: they create their own little subdir in /usr/local/lib, so that they can add even more rotten little paths both to the Linux executable path and the Ldconfig path. This sort of behavior is really crazy to do, but that's what all those ports authors do, those who must install their libraries, (their SYSV libs, understand) to /usr/local. Above and beyond this, all the applications, (and not just browsers, ev
Re: Linux executable picks up FreeBSD library over linux one and breaks
Alex Dupre wrote: Alexander Leidinger ha scritto: To achieve this goal we have 2 possibilities, either we install everything into LINUXBASE and install a wrapper in LOCALBASE, or we install everything in a safe location in LOCALBASE. The first part requires that the maintainers of the linux program play some tricks in their port (plist and/or Makfile). If they fail to do this, it increases the load of portmgr from time to time (build failures on the build cluster). In the second case (install into a safe place in LOCALBASE), portmgr is out of the loop, as if something goes wrong, the port maintainer and/or emulation@ is asked for help, as it is a bug of the port. I admit that probably I'm using only one or two linux applications and I've never created a linux port, but I think the right way is the former possibility, the latter seems a hack to me. It could be harder for unexperienced maintainers, but once we defined the correct way to add a wrapper in LOCALBASE (and put it in the porter's handbook), I think the work for maintainers/committers should be quite easy. What are the other issues that make the former solution so difficult? Are you saying that adding a wrapper to every single linux app is the right way to go? And just putting things in their defined spots (as you've been doing since yoiu began using Unix, sticking libs in /usr/lib and executablees in /usr/bin, and addons in the same spots in /usr/local) is wrong? I am saying, you have a new exec type, stick those in their new spots, then they all run without any wrappers, just working as things have been working since unix began. I guess I might be wrong, but I have to say, wrapping everything really does seem to me to be the hack. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Linux executable picks up FreeBSD library over linux one and breaks
Alex Dupre wrote: Chuck Robey wrote: I guess I might be wrong, but I have to say, wrapping everything really does seem to me to be the hack. Call it a wrapper, call it a symlink, but it seems to me that you don't like linux libs in LOCALBASE *and* you don't like executable references in LOCALBASE (and these are the only two possibilities exposed by Alexander). I prefer the wrapper/symlink, because I think all linux stuff should be in /compat/linux. What do you propose, instead? (Until tomorrow, I won't be able to get my mail fixed to the point that my mail will get thru to hackers, but I will send this anyhow, in the hopes that maybe ...) I'm sorry if I was not clear, I wish to do what hier(7) seems to be telling me. to put all linux executeables into the compat tree, into /compat, which is a symlink to /usr/compat, and underneath there, the correct name for each executable type, in this case into /compat/linux. For example, llibraries would go into /compat/linux/usr/lib (realize that most Linux software ignores /usr/local/, I don't care for that, but if it's restricted to happening in /compat/linux then it's acceptable to me at least). This makes for a single name that needs to go into linux's ldconfig list instread of the mess that's mismanaged now, and an equally simple setup for the linux PATH. Easy was to segrregate all binaries, by their arch, nice and predictable, not needing to be extended for each new library. This just seems like an obvioous thing to me, I'm sorry if I let that make me skip details. No use oif LOCALBASE or LINUXBASE, unless you wanted to define LINUXBASE to be "linux" and then vector things into /compat/$(LINUXBASE), something like that would make sense. But no use of LOCALBASE. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've lost the printing of all of th e messages you normally see, when you are booting yoiur machine (you know, mostly probe messages. I used to see them on this box. When I made my first kernel, I had begun (obviously, as we all do) with GENERIC as a base, but changing the first loaders.hints and the kernel, that's the last I saw of booting messages. To illustrate what I *do* see, I watch the first character of that little spiller, but only the very first char, because that's when it stops working, right after sicking the first char. Thbe nest thing I see, maybe 30 seconds later, is a Login: request. Any notion what I could do to get my booting messages back? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHavEyz62J6PPcoOkRAg7vAJ9zneAz5IuI6kwLOK31ZjeffQdt4gCfZCqF +z0b/+Q+ZHp5MDGcADSy+Go= =AOCE -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: > On Thu, Dec 20, 2007 at 05:48:18PM -0500, Chuck Robey wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I've lost the printing of all of th e messages you normally see, when you are >> booting yoiur machine (you know, mostly probe messages. I used to see them >> on >> this box. When I made my first kernel, I had begun (obviously, as we all do) >> with GENERIC as a base, but changing the first loaders.hints and the kernel, >> that's the last I saw of booting messages. >> >> To illustrate what I *do* see, I watch the first character of that little >> spiller, but only the very first char, because that's when it stops working, >> right after sicking the first char. Thbe nest thing I see, maybe 30 seconds >> later, is a Login: request. > > Sounds like your console is configured to a different device. > Maybe it is configured to serial while you are waiting on vga. > >> Any notion what I could do to get my booting messages back? > > Switch the console to the device you are looking at. > You can easily check the configured console by running conscontrol. > Maybe you've lost the device hint for your console device to flag > it as beeing a possible console candidate. OK, when I run conscontrol, it tells me I am using the dcons console. I looked at the man page for concontrol (and I've been gone from FreeBSD so long, I wasn't even awaare of conscontrol at all) and it informed me I am using the dcons device. I am not aware of any others, I was hoping that if there were such, there would be references to them in either the dcons or conscontrol man pages, but no lock. Is dcons good enough? You understand I would be ecstatic if it wasn't 9and if I could set it to something else, and thereby get my booting messages back.) I checked my kernel config file, it does indeed list the dcons device. Have any other ideas, I'm really listening here. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHbIWgz62J6PPcoOkRAigoAJ99PTNEEeK8LsBEXAtQS8Sc4tan2ACdESgM oBKqPU4TripnypwtKckxt6A= =r7GD -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: > OK, when I run conscontrol, it tells me I am using the dcons console. I > looked at the man page for concontrol (and I've been gone from FreeBSD so > long, I wasn't even awaare of conscontrol at all) and it informed me I am > using the dcons device. I am not aware of any others, I was hoping that if > there were such, there would be references to them in either the dcons or > conscontrol man pages, but no lock. Is dcons good enough? You understand I > would be ecstatic if it wasn't 9and if I could set it to something else, and > thereby get my booting messages back.) I checked my kernel config file, it > does indeed list the dcons device. > >> dcons has no output as such, it depends on further support. >> dcons for example allows console access over firewire. >> You likely want consolectl as your configured console device. >> I can just repeat myself: you must have missing some device hints, >> since the device as such works fine but is not used as console. >> See if conscontrol lists consolectl as available console devices, >> if not than you are surely missing a hint if yes then you have >> explicitly configured you console to be on dcons. I wish you'd given more examples, because the concontrol man page is extremely unhelpful, but I will see if I can prompt you into it, by providing what comes out of my running conscontrol: TCSH-april:root:/home/chuckr:#105-12:23>conscontrol Configured: dcons Available: dcons,gdb Muting: off If you use the "list" parameter to conscontrol, the same printout results. I *think* you might be saying that I should see something dealing with consolectl, nothing resu;ting even from man -k consolectl. I did find the file /dev/consolectl, but I can't figure out the use of it. Hmmm, I found a hint on an old email, hinting that the command "conscontrol should have been used to add a console. I just tried using the ctl-alt-f1 combo to get onto ttyv0. I did a tty, this proved I was in fact on ttyv0, so i tried to do a "conscontrol add /dev/ttyv0, but what came back was "device not configured". I think I'm close here, so what should my console device be? > > Have any other ideas, I'm really listening here. > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHbU41z62J6PPcoOkRAhYiAJ0WMob4kfBZFautZJLbbrOm6HVdzQCgjRJ3 +BYHMNjaRLrYjANPsizWeck= =aUxK -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dag-Erling Smørgrav wrote: > Chuck Robey <[EMAIL PROTECTED]> writes: >> I've lost the printing of all of th e messages you normally see, when you are >> booting yoiur machine (you know, mostly probe messages. I used to see them >> on >> this box. When I made my first kernel, I had begun (obviously, as we all do) >> with GENERIC as a base, but changing the first loaders.hints and the kernel, >> that's the last I saw of booting messages. > > You say something stopped working after you fiddled with some config > files, but you don't show us those config files nor even tell us *which* > config files you modified in terms that we can understand (there is no > such thing as loader.hints). Dag, I looked through all my older messages, I couldn't see where I'd given you the misimpression about stuff stopping working when I made my first kernel. Teh target then was to maintain booting, which it did, and I don't remember anything specific that stopped working. The sound, for instance, didn't work before, and also didn't immediately work thereafter. The only striking change, beyond jumping to current, was the uname print, and the sudden jarring cessation of all the boot messages (that, I could hardly have missed, it worried me more than a little at first, I though the machine had hung during boot!) Anyhow, I don't have that first config file. I have the one I'm using now, so in the assumption that you would like to see that, I'm going to paste it at the end. The only thing that I can comment on, so far, is that my motherboard hasn't got any serial devices, no uarts, so I don't have any ttyd0 device, and that's (I think) why it doesn't show up on any conscontrol listing. Is there a better device to have set up, as my console output? Note that my kernel config file has the sc (syscons, right?) device, in case either I have done that wrong, or maybe it might mean I should spec some specific device to conscontrol. #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident APRIL # To statically compile in device wiring instead of /boot/device.hints hints "APRIL.hints" # Default places to look for devices. makeoptions DEBUG=-g# Build kernel with gdb(1) debug symbols options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options MD_ROOT # MD is a potential root device options NFSCLIENT # Network Filesystem Client options NFSSERVER # Network Filesystem Server options NFS_ROOT# NFS usable as /, requires NFSCLIENT options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_43TTY# BSD 4.3 TTY compat [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev #optionsADAPTIVE_GIANT # Giant mutex is adaptive. options STOP_NMI# Stop CPUS using NMI instead of IPI options AUDIT # Security event auditing # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Supp
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: > On Sun, Dec 23, 2007 at 01:12:49PM -0500, Chuck Robey wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Dag-Erling Smørgrav wrote: >>> Chuck Robey <[EMAIL PROTECTED]> writes: >>>> I've lost the printing of all of th e messages you normally see, when you >>>> are >>>> booting yoiur machine (you know, mostly probe messages. I used to see >>>> them on >>>> this box. When I made my first kernel, I had begun (obviously, as we all >>>> do) >>>> with GENERIC as a base, but changing the first loaders.hints and the >>>> kernel, >>>> that's the last I saw of booting messages. >>> You say something stopped working after you fiddled with some config >>> files, but you don't show us those config files nor even tell us *which* >>> config files you modified in terms that we can understand (there is no >>> such thing as loader.hints). >> Dag, I looked through all my older messages, I couldn't see where I'd given >> you the misimpression about stuff stopping working when I made my first >> kernel. Teh target then was to maintain booting, which it did, and I don't >> remember anything specific that stopped working. The sound, for instance, >> didn't work before, and also didn't immediately work thereafter. The only >> striking change, beyond jumping to current, was the uname print, and the >> sudden jarring cessation of all the boot messages (that, I could hardly >> have missed, it worried me more than a little at first, I though the >> machine had hung during boot!) > > We all know that you have fiddled with a config file, because that's the > only possible reason for this to happen. > >> Anyhow, I don't have that first config file. I have the one I'm using now, >> so in the assumption that you would like to see that, I'm going to paste it >> at the end. The only thing that I can comment on, so far, is that my >> motherboard hasn't got any serial devices, no uarts, so I don't have any >> ttyd0 device, and that's (I think) why it doesn't show up on any >> conscontrol listing. Is there a better device to have set up, as my >> console output? Note that my kernel config file has the sc (syscons, >> right?) device, in case either I have done that wrong, or maybe it might >> mean I should spec some specific device to conscontrol. >> >> >> # To statically compile in device wiring instead of /boot/device.hints >> hints "APRIL.hints" # Default places to look for devices. > > We all need to see your APRIL.hints and as already asked for your > /boot/device.hints > Why do you need statically compiled in hints at all? > This is normaly only done for exotic boot environments (e.g. on embedded > systems) where the normal bootchain can't be used. > OK, I think I might finally be understanding you a bit better (I hope so, at least, I'm surely not trying to make things hard). The config file I was always referring to, it's the kernel config file (I named it APRIL in the config file). I've lost that first APRIL, the one where the boot messages stopped. I think the other confusion lies in what broke: not hardware: the printing of the boot messages is what broke, that's all, nothing else. My goal in recompiling was only (besides jumping to current) was to get rid of all the devices I didn't use, in GENERIC. I'd intended to attach my APRIL listing to the last mail, but I must have screwed that up, so I'll list it here at the end (I'm going to paste it right now, for insurance's sake, but in the interest of brevity, I deleted out all the lines that I'd just commented out, so as to save the mail KBs). As far as the hints files go, I'm embarrassed to admit that I don't understand the difference between the hints file that I name (APRIL.hints) in my config file, and the device.hints in the man page of that name. I have experimented with naming the file as device.hints, as APRIL.hints as I named it in the kernel config file, and without one completely (rebooting with each). I have also tried using kenv to automatically generate a config file, and making one by starting with the GENERIC.hints, and subtracting those device lines that I knew I wasn't using. I have to admit I was somewhat nonplussed by the fact that the kenv command came out with a binary format when I piped the output to a file. I rebooted with each, so I could see if maybe one combination might be right. The device.hints man page didn't explai
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dag-Erling Smørgrav wrote: > Chuck Robey <[EMAIL PROTECTED]> writes: >> As far as the hints files go, I'm embarrassed to admit that I don't >> understand the difference between the hints file that I name (APRIL.hints) >> in my config file, and the device.hints in the man page of that name. > > OK, so you customized your device hints file. Don't do that; that's > what broke your console. Don't compile device hints into your kernel, > either. Just use the stock device.hints that mergemaster installs in > /boot, and you will be fine. There is no need to modify the hints file > except in very special circumstances, and it has no effect on the size > of your kernel. > > DES After a rather huge amount of experimentation (I don't know if you saw, I lost my keyboard for all my X11 stuff, when I tried to omit the number of available vty's down from 16 to 8, but removing that single line from my kernel config fixed the keyboard access problem). Anyhow, in the midst of all the screwing around, I now find that, on the Ascii-graphics FreeBSD loader UI, if I choose Option #5 (verbose loading) then the printing of the regular probe messages starts back up (this is NOT the verbose probe messages, it's the printing of the regular probing messages.) I have to admit, I don't clearly know the difference, in setting the variables, between verbose loading the verbose probing. I know the difference in what prints, but I don't know how to set this up permanently without getting me that verbose probing, which I would like to avoid. Any idea how to set that up.verbose loading but regular probing, the same as hitting the option #5? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHdECiz62J6PPcoOkRAreqAJ9WdUryTFSnGl5ttUn7+KUfYYk76gCfXfT7 1v6oyGZFJJcSPsH+8tPOkBs= =gJtu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dag-Erling Smørgrav wrote: > Chuck Robey <[EMAIL PROTECTED]> writes: >> Anyhow, in the midst of all the screwing around, I now find that, on the >> Ascii-graphics FreeBSD loader UI, if I choose Option #5 (verbose loading) >> then the printing of the regular probe messages starts back up (this is NOT >> the verbose probe messages, it's the printing of the regular probing >> messages.) I have to admit, I don't clearly know the difference, in >> setting the variables, between verbose loading the verbose probing. I know >> the difference in what prints, but I don't know how to set this up >> permanently without getting me that verbose probing, which I would like to >> avoid. > > I have absolutely no idea what "verbose loading" and "verbose probing" > mean. All I know of is the boot_verbose loader variable, which enables > additional kernel messages. It does not affect the way the kernel is > loaded, or the way devices are probed. > > DES I'm sorry, Dag, but I am myself having problem describing it. I have been asking for names, but while I get some guesses about the loss of printing, they haven't given me names to use. I see two items that I can get, when booting. If I stick "-v" in /boot.config, then when the kernel probes, all the probes are verbose. Stuff like my HDaudio card print incredibly verbose listings. OK, that's what I will call here Print#1 The other thing is what I can see if I see the ascii-graphical loader (the picture, in ascii-graphics, either of a BSDaemon, or of the letters "FreeBSD", and a list of about 9 options for booting. If I select item #5, then I get a listing. The listing is quite distinct from what I identify as Print#1, so I'll call this Print#2. If I either hit return at that ascii booting menu (to get the default) or select item #1, then when it boots, I get no print at all: I see the very first spinner character (but it never prints the second one), and the next thing I see, it's printing "Login:". This Print#2 looks like the old non-verbose booting messages that I used to see, before I lost the printing of all booting messages. So, what do you call Print#1 and Print#2? Sure would help out, if folks would answer these, and not only answer the real question, which is why my ordinary non-verbose printing of booting messages went away. If you want, I can tell you, referencing the "verbose loading", that's my Print#2 When I talked about "verbose probing" I am talking about the Print#1. The reason I grabbed those definitions (clearly in desperation) is because it seems to me that Print#1 is called out as device probing is starting, and Print#2 is called out before all loading has begun. Yes, I know that those two times abut one another, and aren't particularly good names. BUT note that when you supply a name, that one I guarantee I will stick with, religiously, for now on. I'm beginning, right now, to wonder: I increased the dmesg-buffer to 64K, I wonder if maybe that might possibly cause the bug? I know it shouldn't, but it wouldn't be the first time this week that I found weird behaviour in the kernel: if you set the number of vtys from the default 16 down to 8, that caused me to lose keyboard input to my X11. I got REALLY lucky to find that one, but it's a testable fact. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHdpjYz62J6PPcoOkRAlChAJ9n7LY7AESihXhBZ01FnZL/e1ZrXQCfZJR1 NjcCDKTU+eT0ES46T2SZMRQ= =p/bh -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Chadwick wrote: > On Sat, Dec 29, 2007 at 09:42:38PM +0100, Erik Trulsson wrote: >> If you do not see any boot messages at all, then my guess is that you >> probably have messed around with /boot/device.hints (or compiled in a hints >> file in the kernel) and removed or disabled the hints for the video >> adapter/system console. > > We've confirmed already in this thread that that's exactly what he's > done. But he's still yet to include any details about what all he > changed and the APRIL.hints file he's using his in kernel configuration > (rather than using /boot/devices.hints, which is what he should be > using). > > This thread is running in circles. > A large part of the reason that this thread seems to be running in circles is because the names I have for things are extremely poor. In my previous posts, I thought to provoke someone into telling me the correct names for things by using names more reminiscent of grade school, but to my astonishment (and embarrassment) others have replied using that ridiculous nomenclature "Print#1 and Print#2". Doesn't that seem more than a little ridiculous to you? To stop me from using words out of kindergarten, you merely need to supply me with better ones (heck, point me at a proper man page that uses them, I can read) and I will immediately begin using the better names. I mean, isn't this a bit ridiculous? OK, I'm going to reply to one of the other posts, regarding the actual topic, but I wanted this plea not to become submerged in other concerns. The only reason to reply to this post would be to give me better names to use, as described in my other posts. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHeA7Nz62J6PPcoOkRAtLOAJ9IBmbdX8oAv95fA+jtYT+rnPxrogCfRtb0 Y3tafYbMjBFXQbtSLWaFnQI= =XwMF -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Jeremy wrote: > On Sat, Dec 29, 2007 at 01:58:32PM -0500, Chuck Robey wrote: >> booting. If I stick "-v" in /boot.config, then when the kernel probes, all >> the probes are verbose. Stuff like my HDaudio card print incredibly >> verbose listings. OK, that's what I will call here Print#1 >> >> The other thing is what I can see if I see the ascii-graphical loader (the >> picture, in ascii-graphics, either of a BSDaemon, or of the letters >> "FreeBSD", and a list of about 9 options for booting. If I select item #5, >> then I get a listing. The listing is quite distinct from what I identify >> as Print#1, so I'll call this Print#2. If I either hit return at that > > There are no distinct names for what you call Print#1 and Print#2 > because these outputs should be identical. Within the kernel, the > verbosity is controlled by a boolean flag "bootverbose" - which is > visible via sysctl as "debug.bootverbose". I just went thru a long series of reboots, so I can make really certain I have this correct. I had some stuff wrong before, I can see that. The state really is, the only way I can provoke printing of boot messages during booting is to call out a verbose boot. If I do that, then the boot messages DO print during booting, and examination afterwards shows a big file (~ 60K in size). This happens if I use /boot.config==-v, or if I enter option #5 to the beastie menu, or even if I call out a manual loader run, and enter boot -v at the prompt. If I do none of those things, it will not print boot messages. After booting, if I do a "dmesg > dm" then the resulting file is only about 10k in size, and things like the enormous pci probing don't show up. At this moment, I'm in a boot that wasn't printed, and I just got a 0 back from a "sysctl debug.bootverbose" > > What differences are you seeing between the two outputs? > What is the content of your /boot.config and /boot/loader.conf (and > any other files you have changed in /boot)? Right now, I moved my /boot.config to /notboot.config. My loader.conf is boot_mute="NO" verbose_loading="YES" linux_load="YES" #snd_hda_load="YES" #beastie_disable="NO" #loader_logo="beastiebw" nvidia_load="YES" The nvidia thing is because I brought to sources for the nvidia graphics card I use to the point where it compiles for current, and I have that working ok (although I haven't found any way to test it yet). I do notice that I have verbose_loading set to YES, but that never seemed to show any effects. I have experimented (not recently, but after I lost the boot messages) and I never saw any differences from it. The boot_mute line was another of my efforts to get printing to start up, it didn't have any effect either. > > Can you please provide the output from and "kenv" > in the the above two cases as well as a default boot. Sure. "sysctl debug.boothowto" returns -2147418112, any idea what that means? The kenv stuff is long, but I'll stick it at the end, here. > I presume you aren't seeing any of this odd behaviour when you boot > from an install CD. Never tried it. I have a trash ide disk that I initially booted from, before I got my raid up, it's still available to boot from, and yes, it prints it's boot messages during boot, just fine. When I switch to that, it's the whole / including /boot and /usr, it's 80G big. It would really help if you reverted back to a > stock GENERIC kernel, with no local mods in / or /boot and then > started re-applying your changes one at a time to see what has gone wrong. Hoping not to have to do that. but if this here doesn't seem tog et anywhere with it, that's the only choice I will have if I want to see things fixed. Luckily for me, that trash ide drive is available to me still, so I'd have to do that one. Just didn't want to do that, I have the audio still to work at, and then some others things fro friends, but if there's no choice, then I guess I will have to. > >> I'm beginning, right now, to wonder: I increased the dmesg-buffer to 64K, I >> wonder if maybe that might possibly cause the bug? I know it shouldn't, >> but it wouldn't be the first time this week that I found weird behaviour in >> the kernel: if you set the number of vtys from the default 16 down to 8, >> that caused me to lose keyboard input to my X11. > > None of this should happen either. > Well, Des explained the x11 thing, it turns out that you must turn "off" the highest numbered vty, so that X11 has a place to land. That nearly fooled me, because it's se
Re: printing boot probe messages
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Peter Jeremy wrote:
> On Sun, Dec 30, 2007 at 06:13:53PM -0500, Chuck Robey wrote:
>> during booting is to call out a verbose boot. If I do that, then the boot
>> messages DO print during booting, and examination afterwards shows a big
>> file (~ 60K in size). This happens if I use /boot.config==-v, or if I
>> enter option #5 to the beastie menu, or even if I call out a manual loader
>> run, and enter boot -v at the prompt.
>>
>> If I do none of those things, it will not print boot messages.
>
> This doesn't really make sense because the only difference is code like
> if (bootverbose)
> printf("Lots more detail\n");
> and there shouldn't be any side-effects.
>
>> After
>> booting, if I do a "dmesg > dm" then the resulting file is only about 10k
>> in size, and things like the enormous pci probing don't show up.
>
> That makes sense.
>
>> At this
>> moment, I'm in a boot that wasn't printed, and I just got a 0 back from a
>> "sysctl debug.bootverbose"
>
> That is also correct.
>
>> Right now, I moved my /boot.config to /notboot.config. My loader.conf is
>>
>> boot_mute="NO"
>
> I think this is your problem. The kernel doesn't look at the value of
> the environment variable, just whether or not it is set. Try removing
> or commenting out this line and check for other occurrences of "boot_mute"
Fantastic, that was it! There is a strong chance that at some point, I
also had something wrong with my device.hints, because that boot_mute line
wasn't in there when my non-printing problems began, I put it in while
searching for something to make the probes print. During this, I think I
finally got my worst misunderstanding, that of how to formulate a good
device.hints, corrected.
Anyhow, great to finally have this fixed, thanks, now I can get back to my
real problems (which I am not hitting the list with).
>
>> verbose_loading="YES"
>
> verbose_loading is different to boot_verbose. The former makes the forth
> boot loader more verbose, the latter is passed onto the kernel and makes
> it more verbose.
>
>> Sure. "sysctl debug.boothowto" returns -2147418112, any idea what that
>> means?
>
> It's a bitmask of values defined in
> -2147418112 == 0x8001 == RB_BOOTINFO | RB_MUTE
>
> The "RB_MUTE" explains the lack of console messages and is caused by
> the boot_mute="NO" in your kenv output. Other than that, the kenv
> all looks reasonable.
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHeoX3z62J6PPcoOkRAgsfAJkBgbRWWnT1AOiWhZuRMJKOKGYi+ACbBpTd
ZjjQq71Ll9ZjUNYlGHTByoc=
=AdUW
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
nvidia working?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering ... I have (I think) nvidia working on my box, or at least, I am calling out the nvidia driver in the xorg.conf, but I was wondering if there is any program that only works with the nvidia hardware, some way I can absolutely prove that I have the real nvidia card working here? Before I had it working, I was using the vesa driver, and most things look exactly the same, and if I could fine some program that shows the 8600GTS's abilities, I would sure like that. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHi8Kdz62J6PPcoOkRAlGaAJ0SR7/FCKHnAnU35zlfXV5WKjZ+aACeLSgq uDoVu+bTe2m6VCwYCn1BmMY= =I7gG -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nvidia working?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Nielsen wrote: > Quoting Chuck Robey <[EMAIL PROTECTED]>: >> I was wondering ... I have (I think) nvidia working on my box, or at >> least, I am calling out the nvidia driver in the xorg.conf, but I was >> wondering if there is any program that only works with the nvidia >> hardware, some way I can absolutely prove that I have the real nvidia >> card working here? Before I had it working, I was using the vesa >> driver, and most things look exactly the same, and if I could fine some >> program that shows the 8600GTS's abilities, I would sure like that. > > btw -questions would probably have been a better forum for this question > than -hackers. > True, but I didn't open this thread up, I just grabbed onto the tail of one that was already opened for me. It was opened on hackers, and I figured it would be too much, both to hijack a thread because it seemed to be ending, AND also to redirect it to -questions. I know I get no credit for realizing that another list would have beeen better, most especially because I figured that multimedia would have been the better list, not - -questions. > The most straightforward approach is probably to review the output of > your Xorg log, e.g. /var/log/Xorg.0.log. Output from the nvidia driver > will be prefixed by NVIDIA (rather than VESA or NV if you were using a > different driver). > > There is also x11/nvidia-settings port. It's a control panel of sorts > that will show you nvidia-specific information. In theory it lets you > control some settings as well but personally I've never found it useful > for that. YMMV. > Now, THAT's what i was after, I figure that nvidia-settings thingy ought to answer my "is my nvidia card working in nvidia mode?" question well enough. > JN > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjBgYz62J6PPcoOkRAqGtAJ9CSfMBnrfTUAgNw7P9KDU832wedACgkfes +55Sx6lrv+bKRrI/wqZvbDU= =PFQt -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nvidia working?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Garrett Cooper wrote: > On Jan 14, 2008, at 12:26 PM, John Nielsen wrote: > >> The most straightforward approach is probably to review the output of >> your Xorg log, e.g. /var/log/Xorg.0.log. Output from the nvidia driver >> will be prefixed by NVIDIA (rather than VESA or NV if you were using a >> different driver). >> >> There is also x11/nvidia-settings port. It's a control panel of sorts >> that will show you nvidia-specific information. In theory it lets you >> control some settings as well but personally I've never found it >> useful for that. YMMV. OK, that left mre a ton of questions, but I think some time spent looking at files might answer them, so in case I can't answer them all, I'll be back at you. Thanks! >> JN > > Yeah, I agree on both points: > > 1. Xorg.*.log will most likely yield the info you need about the nvidia > driver. X -probe may as well.. > 2. nvidia-settings was sort of useless for my purposes.. you may or may > not discover that as well after using the tool. Its Windows counterpart > is much more useful. > > Cheers, > -Garrett > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjBaez62J6PPcoOkRApClAKChGW3QQgmDP3pR2XLkd4a2kM8lTQCdEy+j Tb6lrwjGIJvxsbMFAhNu2w0= =Xmxz -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: nvidia working?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Nielsen wrote: > Quoting Chuck Robey <[EMAIL PROTECTED]>: >> I was wondering ... I have (I think) nvidia working on my box, or at >> least, I am calling out the nvidia driver in the xorg.conf, but I was >> wondering if there is any program that only works with the nvidia >> hardware, some way I can absolutely prove that I have the real nvidia >> card working here? Before I had it working, I was using the vesa >> driver, and most things look exactly the same, and if I could fine some >> program that shows the 8600GTS's abilities, I would sure like that. > > btw -questions would probably have been a better forum for this question > than -hackers. > > The most straightforward approach is probably to review the output of > your Xorg log, e.g. /var/log/Xorg.0.log. Output from the nvidia driver > will be prefixed by NVIDIA (rather than VESA or NV if you were using a > different driver). > > There is also x11/nvidia-settings port. It's a control panel of sorts > that will show you nvidia-specific information. In theory it lets you > control some settings as well but personally I've never found it useful > for that. YMMV. Thanks! Looks like I really do finally have that card/driver working right, too. Sure 'preciate the ideas. > > JN > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHjj9wz62J6PPcoOkRAjmBAJ405DDYxex5XhZIXm7X+7OVJghXwwCfWoBp pJ1g1hqT6Vp7AEifghRGx+c= =1XCQ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB Graphic Tablets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just laid hands on a UC-Logic WP8060-TAB08 Graphic tablet, so as to make my work in gimp easier I got this one instead of a Wacom unit for the single obvious reason: $$. It seems to have all the features of the big boys, it's 8" by 6", 1024 intensity levels, chrome bumpers, dual carbs, etc. Anyhow, the probing returns, on my FreeBSD-current system: ums0: on uhub0 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 and in /dev, there isn;'t any ums0 device to be found, and that error #6 is (appropriately enough) Device Not Configured. Well, my first question is, does there exist a tool for USB that let's you view the raw return from the usb probing? I want to see what this device is actually identifying itself as. Actual numeric vendor IDs and product IDs are the sort of thing I'm after. Something a whole lot more detailed that usbdevs, please. Even the dmesg listing (as I show above) hasn't got the numbers and tails I need. Secondly, if I find out (I've contacted a friendly fellow at the manufacturer) that this device works very much like, say, a Wacom device, is there any way to fake out the kernel and force it to think that the device I'm showing it is actually something else, some alias? If there isn't some fairly direct method of doing this, then could someone give me some sort of description of how I might go about sticking in a fake entry that works exactly as a present entry? I figure at least part of it is find out out that object file holds the intended alias target, and also mucking about with the usbdevs file, what else might be required? If it turns out that a completely new driver is required, then I need no immediate answer, because (like I said) I wrote the manufacturer, and I figure they'll take a few years to reply with technical details, and probably tell me how great their Windows driver is. Thanks for whatever I can get. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHrf0sz62J6PPcoOkRAn1dAJ4moCo3iBp4WlNF3/sVH14zKR23fgCePt7B xyKtj04Z/O7oCZKS5fxr2wY= =TE+n -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB Graphic Tablets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian H. Stacey wrote: > Chuck Robey wrote: >> Well, my first question is, does there exist a tool for USB that let's you >> view the raw return from the usb probing? I want to see what this device >> is actually identifying itself as. Actual numeric vendor IDs and product >> IDs are the sort of thing I'm after. Something a whole lot more detailed >> that usbdevs, please. Even the dmesg listing (as I show above) hasn't got >> the numbers and tails I need. > > Hi Chuck, > On list[EMAIL PROTECTED] (A mostly Linux using > crownd though not just, some BSD) They mostly seem to rec. some > (free I assume) MS$ comparible .exe prog for snatching USB traffic > to then analyse / develop for *IX drivers. I don't remember prog name, > but http://lists.alioth.debian.org/mailman/listinfo/sane-devel > Julian Thanks much for the URL, I will definitely look it up. I'm a bit surprised that the SANE folks, who I took to be scanner-oriented, should be interested in graphic tablets. I know, from having used it in the days before I switched back to FreeBSD, that the verbose mode of the Linux usb lister gives all the info you could possibly ask for, I would really rather not use the Linux tool to do that, both for feelings of loyalty, and to be honest, my legs are too shot, and getting back and forth to my now moved Linux machine with the graphic pad is unfun. Maybe I will look at usbdevs and see if it's hackable to make it have a blabbermouth mode. Or, maybe the verbose mode of booting might be more verbose for USB devices? As far as the other side of things, to have a usb device that is identical to one on the list, except the mfr has moved the ident info, and have that driver be inaccessible to FreeBSD seems awfully straitlaced to me. Is it a feeling of the usb kernel developers involved that thjey should impose that level of control on folks? What, in the name of security, maybe? It seems that they might maybe protect it to some lenth, but to remove the abilityu to experiment easily, that sounds a bit too draconian. Is this really the sense of folks here, that no user-provoked experimentation should be allowed? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHrgv6z62J6PPcoOkRAlKoAJ46/zBH/n0Mr2uaUnhF87IR1a8MsgCgm6Lz iaCPsQ1uPPcfGdl3/F+fJ4E= =QjY6 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB Graphic Tablets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian H. Stacey wrote: > Chuck Robey wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Julian H. Stacey wrote: >>> Chuck Robey wrote: >>>> Well, my first question is, does there exist a tool for USB that let's you >>>> view the raw return from the usb probing? I want to see what this device >>>> is actually identifying itself as. Actual numeric vendor IDs and product >>>> IDs are the sort of thing I'm after. Something a whole lot more detailed >>>> that usbdevs, please. Even the dmesg listing (as I show above) hasn't got >>>> the numbers and tails I need. >>> Hi Chuck, >>> On list[EMAIL PROTECTED] (A mostly Linux using >>> crownd though not just, some BSD) They mostly seem to rec. some >>> (free I assume) MS$ comparible .exe prog for snatching USB traffic >>> to then analyse / develop for *IX drivers. I don't remember prog name, >>> but http://lists.alioth.debian.org/mailman/listinfo/sane-devel >>> Julian >> Thanks much for the URL, I will definitely look it up. I'm a bit surprised >> that the SANE folks, who I took to be scanner-oriented, should be >> interested in graphic tablets. > > Err, they're not far as I know, but they often seem to want to grab > byte streams on scanners to then analyse for Sane. I guess what > one wants to later use the grabbed traffic for doesnt matter, so > long as one has the traffic grabbed for analysis ? Well ... OK, I'm having just a bit of a hard time seeing how that would help me in trying to get my graphic tablet working on FreeBSD for my dear old gimp, but I know darn well you're right more often than I am, so I will give a good look at that list anyhow. > >> Is it a feeling of the usb kernel developers involved that thjey > > Maybe current@ or usb@ might know more than hackers@ > Good suggestion, I'll act on it, thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHriYoz62J6PPcoOkRAsfdAJ473iGX+wqmVv29WJ2O9Z8Qj7O3wgCePfH8 dd3BoXE2quZdCs2U2oTF3SA= =dYZc -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB Graphic Tablets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Julian H. Stacey wrote: > Chuck Robey wrote: > Ah, sorry, forgot to say: Using a 2nd PC as traffic monitor. > > You'd issue probe from FreeBSD to USB device using whatever tools, > & the (Gasp! Wash my mouth out with soap!) - MS.EXE prog running > on a 2nd PC would trap a copy of traffic in each direction, > synchronising the 2 as well I believe though never tried it. The > 2nd monitoring (MS) PC uses 2 USB ports, one to copy FreeSBD PC to > tablet device traffic, & the other port to copy tablet to FreeBSD > traffic. ... & you have to make up a special USB cable, eg a male > to female USB extender cable, with tapped copies of signal in each > direction going to 2 extra USB connectors to 2 ports on 2nd monitor > PC. Sane developers seem to do that a lot on new unknown USB > scanners. > > >> but I know darn well you're right more often than I am, so I >> will give a good look at that list anyhow. > > Non tech flippancy: > Chuckle, dreadful thought to be wise! .. BBC's Hitchkikers Guide > To The Galaxy: To leader of bird people: "What do we call you ?" > "Well, some call me the wise .. old .. bird" ponderously said > by John Le Mesurier (Sergeant Wilson in BBC's 'Dad's Army') :-) Well, while I do have extra machines, none of them run MS, so that's no help for me. Kai Wang gave me an extremely nice kernel module, he's named it krepdump, and it's made a really remarkable report. I think I will cut and paste it here, it's obviously full of info, but I don't yet really know how to interpret it. I mailed a better description of the tablet to Kai separately (and also to the usb list), maybe that info might be of help in making sense of this: What follows is all from my dmesg. [report desc size=212] USAGE PAGE Digitizer(13) USAGE Pen(2) COLLECTION Application(1) REPORT ID 7 USAGE Stylus(32) COLLECTION Physical(0) USAGE Tip Switch(66) USAGE Barrel Switch(68) USAGE Eraser(69) LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 REPORT SIZE 1 REPORT COUNT 3 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 3 INPUT ( Const Variable Absolute ) (3) USAGE In Range(50) REPORT COUNT 1 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 1 INPUT ( Const Variable Absolute ) (3) USAGE PAGE Generic Desktop(1) USAGE X(48) REPORT SIZE 16 REPORT COUNT 1 PUSH UNIT EXPONENT 13 UNIT Seconds(51) PHYSICAL MINIMUM 0 PHYSICAL MAXIMUM 8000 LOGICAL MAXIMUM 16000 INPUT ( Data Variable Absolute ) (2) USAGE Y(49) PHYSICAL MAXIMUM 6000 LOGICAL MAXIMUM 12000 INPUT ( Data Variable Absolute ) (2) POP USAGE PAGE Digitizer(13) USAGE Tip Pressure(48) LOGICAL MAXIMUM 1023 INPUT ( Data Variable Absolute ) (2) REPORT SIZE 16 END COLLECTION END COLLECTION USAGE PAGE Generic Desktop(1) USAGE Mouse(2) COLLECTION Application(1) REPORT ID 8 USAGE Pointer(1) COLLECTION Physical(0) USAGE PAGE Button(9) USAGE MINIMUM Button1(1) USAGE MAXIMUM Button3(3) LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 REPORT COUNT 3 REPORT SIZE 1 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 5 INPUT ( Const Array Absolute ) (1) USAGE PAGE Generic Desktop(1) USAGE X(48) USAGE Y(49) USAGE Wheel(56) USAGE Undefined(0) LOGICAL MINIMUM -127 LOGICAL MAXIMUM 127 REPORT SIZE 8 REPORT COUNT 4 INPUT ( Data Variable Relative ) (6) END COLLECTION END COLLECTION USAGE PAGE Generic Desktop(1) USAGE Mouse(2) COLLECTION Application(1) REPORT ID 9 USAGE Pointer(1) COLLECTION Physical(0) USAGE PAGE Button(9) USAGE MINIMUM Button1(1) USAGE MAXIMUM Button3(3) LOGICAL MINIMUM 0 LOGICAL MAXIMUM 1 REPORT COUNT 3 REPORT SIZE 1 INPUT ( Data Variable Absolute ) (2) REPORT COUNT 5 INPUT ( Const Array Absolute ) (1) USAGE PAGE Generic Desktop(1) USAGE X(48) USAGE Y(49) LOGICAL MINIMUM 0 LOGICAL MAXIMUM 32767 PHYSICAL MINIMUM 0 PHYSICAL MAXIMUM 32767 REPORT COUNT 2 REPORT SIZE 16 INPUT ( Data Variable Absolute ) (2) USAGE PAGE Digitizer(13) USAGE Tip Pressure(48) LOGICAL MAXIMUM 1023 REPORT COUNT 1 REPORT SIZE 16 INPUT ( Data Variable Absolute ) (2) END COLLECTION END COLLECTION ums0: on uhub0 ums0: X report 0x0002 not supported device_attach: ums0 attach returned 6 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHr0Xsz62J6PPcoOkRAvBWAKCWF2MEedgY8jnmOmmopS4m7Ww86wCgoEj7 /HeovqjS5bPdU4sbSlONdD4= =aplG -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
problem with ldconfig
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I had a problem with my raid array, and during a fix, I noticed that a thing I'd gotten very used to during my time running Linux was a really bad thing for FreeBSD (the usage of a /boot partition for booting only, to store the kernel, but nothing else). Well, after I had reloaded my raid, and fixed the /boot to be one nice big parition, I have a several very weird things that have cropped up. First one, I'd kept a 100G IDE disk hanging around just in case I hadn't installed the raid right, so I could use it for backup, and this saved me, but now, it no longer boots right. I used to either hit F1 (to boot the 100G IDE, called ad1, ad0 being a cdrom), or I would hit F5 then F1, to boot from the raid, called da0. Well, now, no matter what Function key I hit, it boots from ad1 regardless, and the only way I can boot the raid is the use the #6 option of the beastie menu (to catch the ld cli) and set currdev to disk2s1a, unload, load, then boot. This works fine, but howcome I can't just get it to boot without all this intervention? I have already tried reloading the boot manager into both ad1s1 and da0s1, no change. Well, the other thing that's come up, I can't get my nvidia driver to work along with xorg. It used to show it's arrival both in kldstat, AND also because, in /dev, a file named nvidiactl would show up. This has stopped happening. I had been using the old version 100.14.19, and when I checked the nvidia website, it seems a couple of newer versions had appeared, so I downloaded and built version 169.12. Don't ask me why the crazy version numbering, I looked around for something like a changelog, but had no luck. Anyhow, updating to the newer version wasn't too hard, but didn't show any change. Consulting the /var/log/Xorg.0.log file, even though kldstat says that nvidia.ko is loaded, it never shows a /dev/nvidiactl, and the log file says clearly that it never finds the Nvidia kernel module. Using it with Vesa lets me limp, so I do that, but howcome? OK, I'm not giving my ldconfig problem to you folks, its quite likely its a FreeBSD-current problem, so let those folks handle that one. Boy, I feel like the little boy who cried wolf! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxylOz62J6PPcoOkRAudcAJ9ex65oZUoh+0gf/7WcpNi6KhwsxwCgje63 m4GwVJZrkoU3McfHK1NAArk= =wLpy -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with ldconfig; nvidia loading fixed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Kaduk wrote: > Hi Chuck, > > On 2/28/08, Chuck Robey <[EMAIL PROTECTED]> wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> > [snip RAID/loader interaction] >> Well, the other thing that's come up, I can't get my nvidia driver to work >> along with xorg. It used to show it's arrival both in kldstat, AND also >> because, in /dev, a file named nvidiactl would show up. This has stopped >> happening. I had been using the old version 100.14.19, and when I checked >> the nvidia website, it seems a couple of newer versions had appeared, so I >> downloaded and built version 169.12. Don't ask me why the crazy version >> numbering, I looked around for something like a changelog, but had no luck. >> Anyhow, updating to the newer version wasn't too hard, but didn't show any >> change. Consulting the /var/log/Xorg.0.log file, even though kldstat says >> that nvidia.ko is loaded, it never shows a /dev/nvidiactl, and the log file >> says clearly that it never finds the Nvidia kernel module. Using it with >> Vesa lets me limp, so I do that, but howcome? > > The nvidia kernel module now needs to be loaded at boot-time; > it won't supercede the default vga support if loaded later. > > cat nvidia_load="YES"" >> /boot/loader.conf I'd never heard that about it needing absolutely to load at boot time, but you were absolutely right, I have it working now. It also made my loading problem (I don't know if I complained on hackers about that or not). No, in looking back to by send-cache, I don't think I did, Immediately after I finally got all my raid array proboems fixed, I found really that there was only 1 remaining: booting my raid. I have definitely the boot-manager loaded onto ad1 (my 100G emergency eide disk) and da0 (my raid). I normally would strike f1 to load the eide for emergencies, and f5, then f1, to load from the raid. Well, now, no matter what I press, I load from the eide disk. If I intercept the boot at the beastie menu, and press 6 to get into the loader, I find currdev is _always_ set to disk1s1a (the eide, ad1). If I want to boot the raid, I need to manually do a "set currdev=disk2s1a" then unload, then load the kernel AND manually load all the modules, because loder.conf isn't getting read either. Once I went thru all that, the nvidia driver worked fine, as you predicted, any notion why the loading has gone screwey? I can add one thing: When I initially installed the system, I was just coming back from using Linux for some years, and I forgot that while Linux is in love with using a small /boot partition to store the kernels and the bootloader, FreeBSD isn't. I had stuck the /boot only onto da1s1d, with my root onto da0s1a. I was loading my root via /etc/fstab, I thought, but in fact, I had an old version of a just-useable boot onto myu da1s1a, and that was what was actually booting. When I got rid of the /boot mount line in fstab, and expected things to work ok, this odd refusal to correctly boot from disk2s1a began. Any idea here? Booting is a real drag now. thanks! > > > -Ben Kaduk > > >> OK, I'm not giving my ldconfig problem to you folks, its quite likely its a >> FreeBSD-current problem, so let those folks handle that one. >> >> Boy, I feel like the little boy who cried wolf! >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.4 (FreeBSD) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFHxylOz62J6PPcoOkRAudcAJ9ex65oZUoh+0gf/7WcpNi6KhwsxwCgje63 >> m4GwVJZrkoU3McfHK1NAArk= >> =wLpy >> -END PGP SIGNATURE- >> ___ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "[EMAIL PROTECTED]" >> -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyDsqz62J6PPcoOkRAiHkAJ4irPHgJa8Cdx/0Q/cAK6sfzntLhQCgm/W+ 82dYth4MSJgdPHLuCSo4b70= =wKsU -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with loading 1/2 fixed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Robey wrote: > Ben Kaduk wrote: > >> cat nvidia_load="YES"" >> /boot/loader.conf > > I'd never heard that about it needing absolutely to load at boot time, but > you were absolutely right, I have it working now. > > It also made my loading problem (I don't know if I complained on hackers > about that or not). No, in looking back to by send-cache, I don't think I > did, Immediately after I finally got all my raid array proboems fixed, I > found really that there was only 1 remaining: booting my raid. > > I have definitely the boot-manager loaded onto ad1 (my 100G emergency eide > disk) and da0 (my raid). I normally would strike f1 to load the eide for > emergencies, and f5, then f1, to load from the raid. Well, now, no matter > what I press, I load from the eide disk. If I intercept the boot at the > beastie menu, and press 6 to get into the loader, I find currdev is > _always_ set to disk1s1a (the eide, ad1). If I want to boot the raid, I > need to manually do a "set currdev=disk2s1a" then unload, then load the > kernel AND manually load all the modules, because loder.conf isn't getting > read either. > > Once I went thru all that, the nvidia driver worked fine, as you predicted, > any notion why the loading has gone screwey? I can add one thing: When I > initially installed the system, I was just coming back from using Linux for > some years, and I forgot that while Linux is in love with using a small > /boot partition to store the kernels and the bootloader, FreeBSD isn't. I > had stuck the /boot only onto da1s1d, with my root onto da0s1a. I was > loading my root via /etc/fstab, I thought, but in fact, I had an old > version of a just-useable boot onto myu da1s1a, and that was what was > actually booting. When I got rid of the /boot mount line in fstab, and > expected things to work ok, this odd refusal to correctly boot from > disk2s1a began. Well, found 50% of the problems, my device,hints had a line mis-setting currdev, once I fixed that, it now boots from the right disk. One booting problem remaining: it won't read my /boot/loader.conf. simple file, 2 whole lines: TCSH-april:chuckr:~:#101-12:50>cat /boot/loader.conf linux_load="YES" nvidia_load="YES" that's all, but when (in the loader, preboot) I execute the read-conf command to force it to read the file, it comes back with a syntax error, saying exactly this: " ^ That's it, the single (double) quote, and a caret in column 1 beneath that. Noting else. Could it maybe be something to do with what zi have in rc.conf? I have a line in rc.conf, linux_enable="YES", that's ok along with the loader line, right? > > Any idea here? Booting is a real drag now. > > thanks! > > >> -Ben Kaduk > > >>> OK, I'm not giving my ldconfig problem to you folks, its quite likely its a >>> FreeBSD-current problem, so let those folks handle that one. >>> >>> Boy, I feel like the little boy who cried wolf! >>> ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyEcaz62J6PPcoOkRAmSCAKCPS+g/rJ7A4fjfErjLcoxOzq/IawCcDcat B7Y4mGGyvrtv7sP6Cn097QI= =6eLu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problem with loading all fixed now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Robey wrote: > Chuck Robey wrote: >> Ben Kaduk wrote: > >>> cat nvidia_load="YES"" >> /boot/loader.conf >> I'd never heard that about it needing absolutely to load at boot time, but >> you were absolutely right, I have it working now. > >> It also made my loading problem (I don't know if I complained on hackers >> about that or not). No, in looking back to by send-cache, I don't think I >> did, Immediately after I finally got all my raid array proboems fixed, I >> found really that there was only 1 remaining: booting my raid. > >> I have definitely the boot-manager loaded onto ad1 (my 100G emergency eide >> disk) and da0 (my raid). I normally would strike f1 to load the eide for >> emergencies, and f5, then f1, to load from the raid. Well, now, no matter >> what I press, I load from the eide disk. If I intercept the boot at the >> beastie menu, and press 6 to get into the loader, I find currdev is >> _always_ set to disk1s1a (the eide, ad1). If I want to boot the raid, I >> need to manually do a "set currdev=disk2s1a" then unload, then load the >> kernel AND manually load all the modules, because loder.conf isn't getting >> read either. > >> Once I went thru all that, the nvidia driver worked fine, as you predicted, >> any notion why the loading has gone screwey? I can add one thing: When I >> initially installed the system, I was just coming back from using Linux for >> some years, and I forgot that while Linux is in love with using a small >> /boot partition to store the kernels and the bootloader, FreeBSD isn't. I >> had stuck the /boot only onto da1s1d, with my root onto da0s1a. I was >> loading my root via /etc/fstab, I thought, but in fact, I had an old >> version of a just-useable boot onto myu da1s1a, and that was what was >> actually booting. When I got rid of the /boot mount line in fstab, and >> expected things to work ok, this odd refusal to correctly boot from >> disk2s1a began. > > Well, found 50% of the problems, my device,hints had a line mis-setting > currdev, once I fixed that, it now boots from the right disk. One booting > problem remaining: it won't read my /boot/loader.conf. simple file, 2 > whole lines: I found that my linker.hints was loading one module, so (thinks I) why not try to load them all there, and it workedd like a charm. My loader.conf isn't working now, but it really doesn't bother me all that much. I have only a single problem remaining, it's a audio one, so I am off to the multimedia list, and I thank you for letting me lean on you whilst I stewed in my problems. They all seem to come to me in big waves, never one at a time, and it's not even a thing of one problme having multiple symptoms, they each had t heir own fix. God is watching me and having a nice chuckle over this, I guess. > > TCSH-april:chuckr:~:#101-12:50>cat /boot/loader.conf > linux_load="YES" > nvidia_load="YES" > > that's all, but when (in the loader, preboot) I execute the read-conf > command to force it to read the file, it comes back with a syntax error, > saying exactly this: > > " > ^ > > That's it, the single (double) quote, and a caret in column 1 beneath that. > Noting else. Could it maybe be something to do with what zi have in > rc.conf? I have a line in rc.conf, linux_enable="YES", that's ok along > with the loader line, right? > >> Any idea here? Booting is a real drag now. > >> thanks! > > >>> -Ben Kaduk > >>>> OK, I'm not giving my ldconfig problem to you folks, its quite likely its >>>> a >>>> FreeBSD-current problem, so let those folks handle that one. >>>> >>>> Boy, I feel like the little boy who cried wolf! >>>> > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHyE7Rz62J6PPcoOkRAtjmAKCJPKipDoRaoW5lKch/DEecBnDN7QCfbD8I pN43DuNTPuoxu58VankO0mQ= =7VXA -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Comments on pmake diffs for building on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warner Losh wrote: > From: "Daniel O'Connor" <[EMAIL PROTECTED]> > Subject: Re: Comments on pmake diffs for building on Linux > Date: Tue, 4 Mar 2008 17:01:28 +1030 > >> On Tue, 4 Mar 2008, M. Warner Losh wrote: >>> Greetings, >>> >>> here's a set of diffs that will allow FreeBSD's usr.bin/make to build >>> on Linux. I'm sure they are gross, and I don't plan to commit them >>> (at least not all of them), but I thought I'd post them here to see >>> what people think. >>> >>> I think that the extra config.h includes, the errc -> errx patches >>> and the Makefile.dist patches may be good for the tree. The rest may >>> not meet FreeBSD's source tree policies. >>> >>> Comments? I bet a very large portion of those among us who are professional codes have had been forced at some time to port our make, whether it was the original pmake, or the up-to-date version (I did the most up to date I could manage. Getting something like this done would be a greaat thing, it would very seriously help not just ourselves, but all programmers around the world, but i very seriously doubt you'll ever get it done, Thoe folks who thought that making it the most elegant thing on earth without allowing the least consideration towards cross-compatibility, thoes folks are going to raise political hell on every step of the way, bring in every white elephant argument as often as allowed, and most likely force this project into ports, which is a seriously bad place for it to go, because that advertisess that we, thje FreeBSD group, are committed to not giving it any continuing support, and so no one will be able to rely upon it. The politicians amongst us will kill it, which I'm very osrry to predict >> I did this a while ago when porting some of our code to Linux because it >> builds with pmake.. >> >> Your patches are much nicer than mine however :) > > I was in a hurry, since I thought I could do it in a half hour and > that was faster than explaining things... > >> The tailq stuff could be shoved into a linux.h or some such.. So it's >> more obvious what it's for and why it's there. > > I resisted creating a linux.h, but we'll likely need something akin to > it. When I did some Mac OS X experimentation, I had extensions to > legacy to smooth over the rough edges, but it is too early here. > > Warner > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzvygz62J6PPcoOkRApqaAKCGK8FwwRswtegRjR/AQQ+m8Nx4HgCgj1mz 4yEgWsl3Z7wSx1GvTNdk+dA= =I8th -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Why doesn't autoconf like our /bin/sh?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Meyer wrote: > I've stumbled on to an obscure problem with autoconf 2.61, and I'm not > sure quite what to do with it. I've already sent mail to the autoconf > folks, but I'd like to understand what's going on. > > The problem is that, on a FreeBSD system with only /bin/sh and the > ports zsh as installed shells, if you have SHELL set to zsh when > invoking the autoconf-generated configure script, the script produces > a broken Makefile. It doesn't generate an error, it just complains > that: > > as_func_failure succeeded. > as_func_failure succeeded. > No shell found that supports shell functions. > Please tell [EMAIL PROTECTED] about your system, > including any error possibly output before this > message > > and then runs to completion, with no other indication of an error, and > non in the config.log file either. This has happened on multiple > different FreeBSD systems (including both 6-STABLE and 7-RELEASE), on > multiple autoconf scripts (possibly from multiple versions of > autoconf). > > Installing bash (or presumably any of the other shells that the > configure script looks for) changes this, and it works fine. Setting > SHELL to /bin/sh, or unsetting it, also solves this. > > And of course, if you build from ports, SHELL gets set to /bin/sh, so > there isn't a problem at all (which probably has a lot to do with why > I never noticed it before - the ports systems pretty much covers most > of my needs). > > From poking at things it seems that autoconf isn't happy with /bin/sh > for some reason, even though it works. With SHELL set to zsh, it then > tries that - and again isn't happy. However, it's not so unhappy that > it fails completely, so it tries to run with whatever shell it tried > last. > > My question is, why doesn't the configure script just accept /bin/sh? > After all, it's going to work. Is there an autoconf person who knows > this one? > The top of the configure script I just inspected (the one from print/libxslt) called out, on the top line: #!/bin/sh and so, as long as you do have a real shell there (which you have to have) should really work, BUT I know, from past experience, that many, many Linuxers, when told that their script doesn't work with any shell but Bash, will just tell you "but why don't you run Bash?" as if no one should ever run any other shell. I went to far, back when I ran Gentoo, to try to fix some broken scripts wrt non-bash usage, but no one really cared to fix that kind of thing. It's not going to be a proboem with configure, but it's possible that soome script called by configure is setting it's own shell. Configure probably needs, way up at the top, something like "export SHELL=/bin/sh" but don't hold your breath, and if Linuxers gave it a try, they'd probably want to peg it to bash, and that'd cause worse problems, because Linux and FreeBSD store bash in a different places. But if you're considering some holy war to try to convince Linux folks to correct this, DING DING, let me off at the next stop, please. > Thanks, > http://enigmail.mozdev.org iD8DBQFH1GEnz62J6PPcoOkRAjiMAJ9NfsAKek+9Kjn+nY8cSrhwA1u1MgCeIry3 /T4m3hgOGlA3r2mgrj2Y8W4= =aJDf -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
remote operation or admin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have 4 computers, 1 big FreeBSD-current (4 x86 procs), 2 GentooLinux (1 is a dial AMD Opteron, the other a dual older x86), and 1 MacOSX (dual PPC). I was thinking about looking for two items, I'm not sure if I want one or both of them: either some software to let me merely remotely manage them (public software, mind) or, even better, something to get these disparate hardwares to be able to work together, and (as much as possible) to be able to share work. What might be the best, in terms of ability, and especially the ability to make these work together? If they're not a FreeBSD port, as long as they're reasonably stable, I don't mind porting things, but it needs to be stable on all those CPUs. Could you reo\commend me something? I'll go chase each one down, I won't jump on you if you're wrong, gimme your guesses, ok? Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH3xBFz62J6PPcoOkRAoTnAJ9YmcaNg54AF8Gz7MN+DO5KZKdVzACfcOoM tys5V3b/kiN1+nzDGhtv7Lk= =YAXx -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: remote operation or admin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Chadwick wrote: > On Mon, Mar 17, 2008 at 08:43:49PM -0400, Chuck Robey wrote: >> I have 4 computers, 1 big FreeBSD-current (4 x86 procs), 2 GentooLinux (1 >> is a dial AMD Opteron, the other a dual older x86), and 1 MacOSX (dual >> PPC). I was thinking about looking for two items, I'm not sure if I want >> one or both of them: either some software to let me merely remotely manage >> them (public software, mind) or, even better, something to get these >> disparate hardwares to be able to work together, and (as much as possible) >> to be able to share work. >> >> What might be the best, in terms of ability, and especially the ability to >> make these work together? If they're not a FreeBSD port, as long as >> they're reasonably stable, I don't mind porting things, but it needs to be >> stable on all those CPUs. Could you reo\commend me something? I'll go >> chase each one down, I won't jump on you if you're wrong, gimme your >> guesses, ok? > > I don't understand your question. It's almost like you're asking two > questions: > > 1) How can I manage all of these machines remotely? (E.g. ssh, VNC, > serial console, KVM, etc.) > > 2) How can I harness the power of all of these machines simultaneously? > (e.g. some form of CPU clustering) > > Can you elaborate? > Sure. I suppose what was really driving me was a little daydreaming that I'd been having, about the direction of computing, in the coming few years. Not 20 years ahead, but more likely 2 or 4 years ahead. I was thinking that the present wave towards constructing single-ships with multiple cores on them could only grow in scale, so the real question would be, just how large could "n" get? Then, IF that were true, it begs another question ... right now, we rely upon our fine smp code to do a fairly good job of both managing the administration of those cores, AND the dispatching of jobs amongst them. By now, you've probably smelled the rat: I didn't allow for the difference in hardware that I'd painted: 2 x86 cores, 6 x86_64 cores, and 2 PPC cores. Well, I had to throw all that in if I were to reach for the sky, but I was asking for all that I could possibly get, but not, honestly, unwilling to consider something maybe a bit less than that, if it were easier to consider. What is most important in my considerations are, how might it to possible to stretch our present smp software to be able to extend the management domains to cover multiple computers? Some sort of a bridge here, because there is no software today (that I'm awarae of, and that sure leaves a huge set of holes) that lets you manage the cores as separate computers) so that maybe today I might be able to have an 8 or 10 core system, and maybe tomorrow look at the economic and software possibility of having a 256 core system. I figure that there would need to be some tight reins on latency, and you would want some BIGTIME comm links, I dunno, maybe not be able to use even Gigabit ethernet, maybe needing some sort of scsi bus linkage, something on that scale? Or, is Fiber getting to that range yet? Anyhow, is it even remotely posible for us to be able to strech our present SMP software (even with it's limitation on word size to limit the range to 32 processors) to be able to jump across machines? That would be one hell of a huge thing to consider, now wouldn't it? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4Ub5z62J6PPcoOkRAl9qAJ0fROAdNq/QFFR+7cYix0BvwjGZhQCeIsUH fAWfi7eKgNogAF6uaKpgMoI= =ZIcm -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: remote operation or admin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Moran wrote: > In response to Chuck Robey <[EMAIL PROTECTED]>: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I have 4 computers, 1 big FreeBSD-current (4 x86 procs), 2 GentooLinux (1 >> is a dial AMD Opteron, the other a dual older x86), and 1 MacOSX (dual >> PPC). I was thinking about looking for two items, I'm not sure if I want >> one or both of them: either some software to let me merely remotely manage >> them (public software, mind) or, even better, something to get these >> disparate hardwares to be able to work together, and (as much as possible) >> to be able to share work. >> >> What might be the best, in terms of ability, and especially the ability to >> make these work together? If they're not a FreeBSD port, as long as >> they're reasonably stable, I don't mind porting things, but it needs to be >> stable on all those CPUs. Could you reo\commend me something? I'll go >> chase each one down, I won't jump on you if you're wrong, gimme your >> guesses, ok? > > Your question is extraordinarily vague. I manage multiple systems > remotely using ssh, so I'm not sure what additional "stuff" you want. I left it vague on purpose, because I know I am speaking to a crowd thjat certainly includes folks who know more on the subject than i do, and I was curious as to what woud pop up. I filled in some more of the puzzle in a separate email i just sent (so i won't duplicate that all here), but I have already begun to learn, because, no, I didn't know off all these links. I was thinking (very, very quickly) of putting our smp and the Ganglia thing into a mixer, 2 minutes at high speed, and see what came out? Anyhow, thanks for the links, please don't hesitate to give me more on this subject (this fuzzy cloud?) > > However, here are some links that may provide some help. All of these > are FreeBSD ports, and I'm fairly sure they'll work on Gentoo and > OSX as well: > http://www.webmin.com/ > http://www.cfengine.org/ > http://reductivelabs.com/trac/puppet/ > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4UhHz62J6PPcoOkRAvwFAJ9Y3Q1osqjUJVrQrB89Ya9RczLIowCbBC8V xqihMxtA9lwvt2TEPl8xBN0= =6QlR -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: remote operation or admin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Chadwick wrote: > On Wed, Mar 19, 2008 at 01:01:45PM -0400, Chuck Robey wrote: >> What is most important in my considerations are, how might it to possible >> to stretch our present smp software to be able to extend the management >> domains to cover multiple computers? Some sort of a bridge here, because >> there is no software today (that I'm awarae of, and that sure leaves a huge >> set of holes) that lets you manage the cores as separate computers) so that >> maybe today I might be able to have an 8 or 10 core system, and maybe >> tomorrow look at the economic and software possibility of having a 256 core >> system. I figure that there would need to be some tight reins on latency, >> and you would want some BIGTIME comm links, I dunno, maybe not be able to >> use even Gigabit ethernet, maybe needing some sort of scsi bus linkage, >> something on that scale? Or, is Fiber getting to that range yet? >> >> Anyhow, is it even remotely posible for us to be able to strech our present >> SMP software (even with it's limitation on word size to limit the range to >> 32 processors) to be able to jump across machines? That would be one hell >> of a huge thing to consider, now wouldn't it? > > Ahh, you're talking about parallel computing, "clustering", or "grid > computing". The Linux folks often refer to an implementation called > Beowulf: > > http://en.wikipedia.org/wiki/Beowulf_%28computing%29 > > I was also able to find these, more specific to the BSDs: > > http://www.freebsd.org/advocacy/myths.html#clustering > http://lists.freebsd.org/pipermail/freebsd-cluster/2006-June/000292.html > http://people.freebsd.org/~brooks/papers/bsdcon2003/fbsdcluster/ > Well, I am, and I'm not, if you could answer me one quiestion, then I would probably know for sure. What is the difference between our SMP and the general idea of clustering, as typified by Beowulf? I was under the impression I was talking about seeing the possibility of moving the two closer together, but maybe I'm confused in the meanings? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4VWKz62J6PPcoOkRAtxnAJoDKlh4EgbL17TLUuH3gEDCwt4u9ACePFGh dWFantC9QyS5g9FJh80wXNI= =viHY -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: remote operation or admin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Chadwick wrote: > On Wed, Mar 19, 2008 at 02:03:54PM -0400, Chuck Robey wrote: >> Well, I am, and I'm not, if you could answer me one quiestion, then I would >> probably know for sure. What is the difference between our SMP and the >> general idea of clustering, as typified by Beowulf? I was under the >> impression I was talking about seeing the possibility of moving the two >> closer together, but maybe I'm confused in the meanings? > > SMP as an implementation is mainly intended for single systems with > multiple processors (e.g. multiple physical CPUs, or multiple cores; > same thing). It distributes kernel operations (kernel threads) across > those processors, rather than only utilising a single processor. > > Clustering allows for the distribution of a task (a compile using gcc, > running of certain disk I/O tasks, running multiple userland (or I > suppose kernel, if the kernel had clustering support) threads) across > multiple physical computers on a local network. > > The best example I have for real-world clustering is rendering (mostly > 3D, but you can "render" anything; I'm referring to 3D in this case). > > A person doing modelling creates a model scene using 3D objects, applies > textures to it, lighting, raytracing aspects, vertex/bones animation, > and anything else -- all using their single workstation. Then the > person wants to see what it all looks like -- either as a still frame > (JPEG/PNG/TIFF), or as a rendered animation (AVI/MPG/MJPEG). > > Without any form of clustering, the workstation has to do all of the > processing/rendering work by its lonesome self. This can take a very, > very long time -- modellers aren't going to wait 2 hours for their work > to render, only to find they messed up some bones vertexes half way into > the animation. > > With clustering, the workstation has the capability to send the > rendering request out onto the network to a series of what're called > "slaves" (other computers set up to handle such requests). The > workstation says "I want this rendered. I want all of you to do it". > Let's say there's 200 machines in the cluster as slaves, and let's say > all 200 of those machines are dual-core (so 400 CPUs total). You then > have 400 CPUs rendering your animation, versus just 2 on the > workstation. > > The same concept can apply to compiling (gcc saying "I want this C file > compiled" or whatever), or any other "distributed computing" > computational desired. It all depends on if the software you want to > support clustering can do it. > > Different clustering softwares run at different levels; some might act > as "virtual environments", thus underlying software may not need to know > about clustering (e.g. it "just works"); others might require each > program to be fully cluster-aware. > > Make sense? :-) Not completely yet (I tend to be stubborn, if I carry this too far, tell me in private mail and I will politely drop it). Your use cases show me the differences in size, and *because* of the size, the differences in how you'd use them, and that part I did already know. I'm perfectly well aware of the current differences in size, but what I'm after is what are the real differences, ignoring size, in what they actually accomplish, and how they go about doing it. I'm thinking of the possibility of perhaps finding it it might be possible to find some way to extend the work domain of an smp system to stretch across machine lines, to jump across motherboards. Maybe not to be global (huge latencies scare me away), but what about just going 3 feet, on a very high speed bus, like maybe a private pci bus? Not what is, what could be? And, I have experienced just as many looniees as you have, who ask for some gigantic task, then sit back and want to take the credit and act like a cheerleader, figuring they really got the thing going. Well, I DON'T really want the help, I have in mind a project for me and a friend, with small smallish machine resources, maybe a bunch of small ARM boards. I wouldn't turn down help, but I'm not really proselytizing. Something small, but with a bunch of bandwidth. So, in that case, what really are the differences between smp and clustering, besides the raw current size of the implementation? Are there huge basic differences between the clustering concept and by smp's actual tasks? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH4WUUz62J6PPcoOkRAoJNAJ4o4jpDeVlLG2X6Sk1ccggORyO2GwCgku/s U3w/oylwEgt8CufFZwccfw4= =zbNA -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am having problems with the git out of ports git-fetch keeps on dumping core when I try update of xorg (the initial checkout works ok). I'm running FreeBSD-current ... does anyone have any idea why this might be? When I try to do a gdb -c corefile on the resulting core image, all i get is a couple of thousand empty stack frames. Any idea why that might be, also? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRayEz62J6PPcoOkRAnjLAKCIhWPRyB/Ng17/RiUgkej+9qmp6gCcC2uM 2zxaevhQyF4C3vbsJtURSPQ= =4hoW -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ed Schouten wrote: > * Chuck Robey <[EMAIL PROTECTED]> wrote: >> I am having problems with the git out of ports git-fetch keeps on >> dumping >> core when I try update of xorg (the initial checkout works ok). I'm running >> FreeBSD-current ... does anyone have any idea why this might be? >> >> When I try to do a gdb -c corefile on the resulting core image, all i get is >> a >> couple of thousand empty stack frames. Any idea why that might be, also? > > I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace nearby, > but it seems to be crash inside free(). > My problem is, I can't even get a backtrace on core files, I get thousands of empty stack frames only. The only way I can debug is to do static images and debug the image, not a core file. I don't run anything but current so I can't do any other testing. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRbfAz62J6PPcoOkRAuPAAJ4k6en0g/YlAAUM22Qqj/Kwjx81TwCfR1bx cgq0ip67DuwPJWbfhM61kkA= =H1pB -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Watson wrote: > On Tue, 3 Jun 2008, Ed Schouten wrote: > >> * Chuck Robey <[EMAIL PROTECTED]> wrote: >>> I am having problems with the git out of ports git-fetch keeps >>> on dumping core when I try update of xorg (the initial checkout works >>> ok). I'm running FreeBSD-current ... does anyone have any idea why >>> this might be? >>> >>> When I try to do a gdb -c corefile on the resulting core image, all i >>> get is a couple of thousand empty stack frames. Any idea why that >>> might be, also? >> >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace >> nearby, but it seems to be crash inside free(). > > Application memory errors in HEAD but not in a RELENG_ branch are > frequently a symptom of an application bug unmasked by malloc(3) > debugging enabled in the development branch but not production > branches. It might not hurt to ramp up debugging on your 6.x install to > see if it starts crashing there was well -- see malloc(3) for details, > you'll want to create an appropriate malloc.conf. I didn't see the email where Ed Schouten commented about seeing my problems of seeing no good stack frames, but Robert, I run only -current here, not RELENG_6, so I can't do the testing you speak of. I would want to see if maybe our gcc on - -current might have been made with a default of emitting no stack frames, which I would guess might have this effect. I guess I could test this, and if it's so, recompile all my libraries to undo that, because I abhor doing things that utterly block any troubleshooting at a minimal savings elsewhere. > > Robert N M Watson > Computer Laboratory > University of Cambridge > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqLnz62J6PPcoOkRAlhFAJsHrHTMVaFCdPcUha+1yaFOYyMxuACfY+ms jZRd8WCy9PFcwYICmg636y4= =4PYv -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Watson wrote: > On Tue, 3 Jun 2008, Ed Schouten wrote: > >> * Chuck Robey <[EMAIL PROTECTED]> wrote: >>> I am having problems with the git out of ports git-fetch keeps >>> on dumping core when I try update of xorg (the initial checkout works >>> ok). I'm running FreeBSD-current ... does anyone have any idea why >>> this might be? >>> >>> When I try to do a gdb -c corefile on the resulting core image, all i >>> get is a couple of thousand empty stack frames. Any idea why that >>> might be, also? >> >> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace >> nearby, but it seems to be crash inside free(). > > Application memory errors in HEAD but not in a RELENG_ branch are > frequently a symptom of an application bug unmasked by malloc(3) > debugging enabled in the development branch but not production > branches. It might not hurt to ramp up debugging on your 6.x install to > see if it starts crashing there was well -- see malloc(3) for details, > you'll want to create an appropriate malloc.conf. This is really replying to my own question, because I found what I was missing. I have'nt done any troubleshooting for a long while now (health, down for some years) and the last time I did it, if you had a core file in the same directory as the binary and the sources, gdb would know where to find the symbols on it's own, but it looks like that's changed. Once I explicitly gave the symbols, th8ings began to work ok, so you can stop worrying about my missing stack frames. Now that I have that, I have also the ability to find out where git-fetch died, and I will pretty quickly, that ought to help some. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqVvz62J6PPcoOkRAoKcAJ9c5WFhKf0NkOCgfNFO53jEWpsPUwCdErw4 RY8Ry6WQpgwOKVAPoe+mOUs= =M+hX -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, good day. > > Tue, Jun 03, 2008 at 04:41:40PM -0400, Chuck Robey wrote: >> I am having problems with the git out of ports git-fetch keeps on >> dumping >> core when I try update of xorg (the initial checkout works ok). I'm running >> FreeBSD-current ... does anyone have any idea why this might be? > > What version of Git you're using and what protocol is used for > updating, native git or http? > > Any possibility of using ElectricFence (devel/ElectricFence) > for chasing memory-related troubles? Now that I have gdb working with me again, I am checking the git-fetch image to see where it got lost. If I must bring a tool such as ElectricFence I, I guess I must, just I'm a bit irritated that the git build has one of those make "improvements" (NOT) that instead of telling you the buid line, just gives you "CC sourcename.c" which for anyone who knows code is just irritating, not any sort of help at all. Anyhow, I can do my own testing for a bit now. I can say that I have tried other git archives, and it's the git-fetch that seems to be doing it, not the archive. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqd7z62J6PPcoOkRAg/9AJ9WwjsefME8DKmgIsxgtcAvH5tkIwCgiGrg 72CV1T72i5F4D22LiTY8JOI= =edbu -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eygene Ryabinkin wrote:
> Chuck,
>
> Wed, Jun 04, 2008 at 10:12:55AM -0400, Chuck Robey wrote:
>>>> I'm seeing this on HEAD, not RELENG_6. I don't have a backtrace
>>>> nearby, but it seems to be crash inside free().
>>> Application memory errors in HEAD but not in a RELENG_ branch are
>>> frequently a symptom of an application bug unmasked by malloc(3)
>>> debugging enabled in the development branch but not production
>>> branches. It might not hurt to ramp up debugging on your 6.x install to
>>> see if it starts crashing there was well -- see malloc(3) for details,
>>> you'll want to create an appropriate malloc.conf.
>> I didn't see the email where Ed Schouten commented about seeing my problems
>> of
>> seeing no good stack frames, but Robert, I run only -current here, not
>> RELENG_6,
>> so I can't do the testing you speak of.
>
> There is no need: I had tried this on -STABLE with environment
> variable MALLOC_OPTIONS set to 'J' -- it dumps core. The problem
> seems to be in the git-fetch:
> -
> $ MALLOC_OPTIONS=JA git-fetch --update-head-ok
> Segmentation fault: 11 (core dumped)
> -
> This happens inside git repository of xserver and 100% reproducible
> for my both -CURRENT and -STABLE.
>
>> I would want to see if maybe our gcc on
>> - -current might have been made with a default of emitting no stack frames,
>> which
>> I would guess might have this effect.
>
> The stack seems to be smashed at the second call to
> 'transport_unlock_pack': the argument called 'transport' seems to
> carry the pointer to the area, filled by malloc() with byte 0x5a:
> -
> $ MALLOC_OPTIONS=JA gdb git-fetch
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 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-marcel-freebsd"...
> (gdb) run --update-head-ok
> Starting program: /usr/local/bin/git-fetch --update-head-ok
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x4841de8b in free () from /lib/libc.so.7
> (gdb) bt
> #0 0x4841de8b in free () from /lib/libc.so.7
> #1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
> at transport.c:811
> #2 0x08066927 in unlock_pack () at builtin-fetch.c:56
> #3 0x48468fe3 in __cxa_finalize () from /lib/libc.so.7
> #4 0x4842199a in exit () from /lib/libc.so.7
> #5 0x0804b15b in handle_internal_command (argc=2, argv=0x)
> at git.c:379
> #6 0x0804b8be in main (argc=2, argv=Error accessing memory address 0x10: Bad
> address.
> ) at git.c:414
> (gdb) fr 1
> #1 0x080d8d04 in transport_unlock_pack (transport=0x820a0a0)
> at transport.c:811
> 811 free(transport->pack_lockfile);
> (gdb) print *transport
> $1 = {remote = 0x5a5a5a5a,
> url = 0x5a5a5a5a ,
> data = 0x5a5a5a5a, remote_refs = 0x5a5a5a5a, set_option = 0x5a5a5a5a,
> get_refs_list = 0x5a5a5a5a, fetch = 0x5a5a5a5a, push = 0x5a5a5a5a,
> disconnect = 0x5a5a5a5a,
> pack_lockfile = 0x5a5a5a5a ,
> verbose = -2}
> (gdb)
> -
> I don't believe that __cxa_finalize should call unlock_pack, so
> stack seems to be smashed somewhere before.
>
>> I guess I could test this, and if it's so, recompile all my libraries to undo
>> that, because I abhor doing things that utterly block any troubleshooting at
>> a
>> minimal savings elsewhere.
>
> You don't need to recompile anything to enable malloc debugging.
> The easiest way is to set MALLOC_OPTIONS to the needed malloc
> flags.
Good, that's what I'd figured on my own. I may be slow as mollasses, but I'm
more than a little stubborn, I will track this down (if no one else beats me to
it). I really need my git to work here.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIRqgGz62J6PPcoOkRAs0nAJ0YK0+z9uoUn4Ja97ZG/UECj1OLGgCfffBj
NLCk9xbUINso5d+5QohpefQ=
=slbH
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eygene Ryabinkin wrote: > Chuck, > > Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote: >>> Any possibility of using ElectricFence (devel/ElectricFence) >>> for chasing memory-related troubles? >> Now that I have gdb working with me again, I am checking the git-fetch image >> to >> see where it got lost. If I must bring a tool such as ElectricFence I, I >> guess >> I must, just I'm a bit irritated that the git build has one of those make >> "improvements" (NOT) that instead of telling you the buid line, just gives >> you >> "CC sourcename.c" which for anyone who knows code is just irritating, not any >> sort of help at all. > > No problems, just issue 'make V=1' instead of just 'make' in the > /devel/git -- it will give you all flags and will eliminate > the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized > binary with debug symbols that can be directly traced by gdb with > all symbols and right (unoptimized, as in the sources) code paths. > > For the ElectricFence -- it dumps core just after startup, I don't > know why. So it is not very much usable now, at least for me Well, maybe this will be of help (sure does make me want to look more closely at malloc, doesn't it?) #0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7 (gdb) bt #0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7 #1 0x28437067 in free () from /lib/libc.so.7 #2 0x080d5dd4 in transport_unlock_pack (transport=0x284c1c98) at transport.c:811 #3 0x08066467 in unlock_pack () at builtin-fetch.c:56 #4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7 #5 0x2843b1aa in exit () from /lib/libc.so.7 #6 0x0804b0e3 in handle_internal_command (argc=2, argv=0x) at git.c:379 #7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12 ) at git.c:414 (gdb) Oh, I didn't say this was from a git-fetch.core and a freshly rebuilt image in ports, did I? It is, though. I'm not done here, yet, but maybe your better knowledge of our malloc may help us a bit? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIRqsvz62J6PPcoOkRAsPfAJ4wlm9W5Z1wCvQsVgwkjBor7BMZ5ACgkTW+ F4ahNZpzhJuD2Uru1vsoMQo= =EXb0 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: git problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Eygene Ryabinkin wrote:
> Chuck,
>
> Wed, Jun 04, 2008 at 10:32:27AM -0400, Chuck Robey wrote:
>>> Any possibility of using ElectricFence (devel/ElectricFence)
>>> for chasing memory-related troubles?
>> Now that I have gdb working with me again, I am checking the git-fetch image
>> to
>> see where it got lost. If I must bring a tool such as ElectricFence I, I
>> guess
>> I must, just I'm a bit irritated that the git build has one of those make
>> "improvements" (NOT) that instead of telling you the buid line, just gives
>> you
>> "CC sourcename.c" which for anyone who knows code is just irritating, not any
>> sort of help at all.
>
> No problems, just issue 'make V=1' instead of just 'make' in the
> /devel/git -- it will give you all flags and will eliminate
> the fancies. And 'make V=1 CFLAGS="-O0 -g"' will produce unoptimized
> binary with debug symbols that can be directly traced by gdb with
> all symbols and right (unoptimized, as in the sources) code paths.
>
> For the ElectricFence -- it dumps core just after startup, I don't
> know why. So it is not very much usable now, at least for me.
>
> Thank you.
I think I have it narrowed down to either a problemm in process creation (I
don't believe this one) or, more likely, a problem in managing the crt0 stuff in
managing a process's startup bars. Take a look below and tell me if you agree.
Here's the stack dump:
#0 0x284369f3 in malloc_usable_size () from /lib/libc.so.7
#1 0x28437067 in free () from /lib/libc.so.7
#2 0x080d5dd4 in transport_unlock_pack (transport=0x284c1c98) at
transport.c:811
#3 0x08066467 in unlock_pack () at builtin-fetch.c:56
#4 0x2848b5f3 in __cxa_finalize () from /lib/libc.so.7
#5 0x2843b1aa in exit () from /lib/libc.so.7
#6 0x0804b0e3 in handle_internal_command (argc=2, argv=0x) at git.c:379
#7 0x0804b7ed in main (argc=2, argv=Cannot access memory at address 0x12
) at git.c:414
and here's the lines from git.c, the loop where handle_internal_command gets
called:
/* Turn "git cmd --help" into "git help cmd" */
370 if (argc > 1 && !strcmp(argv[1], "--help")) {
371 argv[1] = argv[0];
372 argv[0] = cmd = "help";
373 }
374
375 for (i = 0; i < ARRAY_SIZE(commands); i++) {
376 struct cmd_struct *p = commands+i;
377 if (strcmp(p->cmd, cmd))
378 continue;
379 exit(run_command(p, argc, argv));
380 }
First I want to comment on that weird line 379, because while it might work, it
sure seems to me to be a very strange and wasteful way to do a fork. I bet
that's some sort of portability hack. Second, the second argument to
handle_internal_command seems to have been a argv=0x, which is very
obviously a bad string pointer
Looking at the top stack frame (main), that frame and the next are deeply
involved in inspecting argv 0 thru 2, and since it's full of garbage, that's
what breaks things. That's NOT malloc, that seems to be either a problem in
process creation or (I think more likely) a problem in the creation of a
process's environment, the crt0 stuff. I'm getting out of my depth, here.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIRrQKz62J6PPcoOkRAnwFAJ9XXb0cy/Rowt+X2uLx1uaYWJdHdACglAe6
dThwRYHJ9f95Qyua/syFsV4=
=yFZR
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
number of /dev/usb nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find how many /dev/usbN bus devices there can be. I'm writing some code that scans them all looking for anything that has my device, but I while I know to start at usb0, just how high do I go? There seem to be 128 device minors, is that the number? (from dev/usb/usb.h) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFISsLxz62J6PPcoOkRAtSTAKCFC8NueSSuJ0yZcVNwdjQie3SZJgCfb0bL AMAwFSbFBySoSVCfqc7R0+M= =MwIo -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: number of /dev/usb nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: > On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I can't seem to find how many /dev/usbN bus devices there can be. I'm >> writing >> some code that scans them all looking for anything that has my device, but I >> while I know to start at usb0, just how high do I go? There seem to be 128 >> device minors, is that the number? (from dev/usb/usb.h) > > There shouldn't be a limit anymore. > I can't see any definition of 128 in usb.h that limits the number of > busses. > The major/minor differenciation is long time ago. > You must be looking at old code. > I was trying to find a good way to do scanning, whjen I create the files like /dev/usb0, how far to go in my loop? Does the lowest available device always get created? That would imply that as soon as I began to get "No such device" errors, I could stop iterating. If the rules for picking device filenames are pretty loose, then I could (for instance) stop scanning, say, 4 numbers past the first "No such device" returnee. Any idea on this? I didn't see this i nthe code, but I just need some sane limit on what filenames to scan about in. I look for item info, and if the usb vendor and prodict look friendly, I just snag the filename involved, and use that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 open. There's more than 1 place that my devices could show, depending on the user's kernel devices. I just want to have some sane limit on how many usb buses I open for my scanning. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIS+m6z62J6PPcoOkRAgBoAJ0XYYfUat/fJDChSybpNtFzCwUr9ACdGxNf UoCeHzvriXfQ+bj5LDxE8vA= =sTcT -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: number of /dev/usb nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Walter wrote: > On Sun, Jun 08, 2008 at 10:16:26AM -0400, Chuck Robey wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Bernd Walter wrote: >>> On Sat, Jun 07, 2008 at 01:18:41PM -0400, Chuck Robey wrote: >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>>> >>>> I can't seem to find how many /dev/usbN bus devices there can be. I'm >>>> writing >>>> some code that scans them all looking for anything that has my device, but >>>> I >>>> while I know to start at usb0, just how high do I go? There seem to be 128 >>>> device minors, is that the number? (from dev/usb/usb.h) >>> There shouldn't be a limit anymore. >>> I can't see any definition of 128 in usb.h that limits the number of >>> busses. >>> The major/minor differenciation is long time ago. >>> You must be looking at old code. >>> >> I was trying to find a good way to do scanning, whjen I create the files like >> /dev/usb0, how far to go in my loop? Does the lowest available device always >> get created? That would imply that as soon as I began to get "No such >> device" >> errors, I could stop iterating. If the rules for picking device filenames >> are >> pretty loose, then I could (for instance) stop scanning, say, 4 numbers past >> the >> first "No such device" returnee. > > This wouldn't work if a USB controller is remove - e.g. a pulling a > cardbus card. > >> Any idea on this? I didn't see this i nthe code, but I just need some sane >> limit on what filenames to scan about in. I look for item info, and if the >> usb >> vendor and prodict look friendly, I just snag the filename involved, and use >> that. Like, a scan of the usb1 bus might yield me a uhid0 which might be my >> meat, whereupon I coulld drop the usb1 open, and replace it with a uhid0 >> open. >> There's more than 1 place that my devices could show, depending on the user's >> kernel devices. I just want to have some sane limit on how many usb buses I >> open for my scanning. > > I never had to deal with this, since writing a USB driver is simple and > as a driver you get informed for each new device. > No need to scan the busses yourself. > But I would say that the most reliable way is to just scan /dev/ for > usb... > Assumptions I never said I was writing a FreeBSD driver... I am writing what Xorg calls an input driver (Xinput). I could rely on the config file, I thought I would try to use a scan in case I can't find the dev the user passes me. I see no reason to write a FreeBSD driver when I can do everything I need within the uhid driver (at least so far, in my test prog). There IS one caveat: I've posted to the FreeBSD-USB list that there is a part of the libusbhid that I can't yet get working. Writing a FreeBSD driver would allow me to use other available data marshalling code, like what's in the ums driver. If I can't interest anyone to comment about the libusbhid, I might be forced down that path, but I don't want to. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFITA5rz62J6PPcoOkRArTGAJ938MKH9L1HRuIpaH3QCy38huJwkQCfUCeF dE0dyEG+GZUMhi8fAIXNfRk= =ddvg -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
FreeBSD hotplugging info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have finished doing all the work and investigation (and test program writing) I need to do, for all of the usb aspects of my grapghic tablet Xorg Xinput driver (well, THEY call it a driver). Yes, I know I've been owrking on it for a while now, but I need to move slowly for personal reasons. I can see that, for very up to date modules, Xorg wants to have hotplugging to work in their input drivers. My work contemplates using the existing FreeBSD devices (my test program uses uhid very nicely). So, I was wondering if anyone knows of any sort of software working in FreeBSD that doesn hotplugging (using dbus would be the way that Xorg contemplates), then could you tell me what it is, so I can look at it? I've already read up on dbus; it seems to be a messaging thing, so I just want to see some example of how dbus would see use in FreeBSD. I figure, since the devices I'm working on are quite inexpensive (about 60 bucks for a 8" by 6" model), it might just turn out to be popular, if I do a really good job of this. That's why I want to cross every T, dot every I. I was going ahead and adapting my test program to the Xinput example I have, when I realized I need the hotplugging feature. Thanks for any help. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIUslLz62J6PPcoOkRAkKuAJ9NS9MEapIX00nbZqFe35bdUnhUNgCfQOKS yufGBK0gpMYXIiOux7HGjmk= =BgYv -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD hotplugging (Hal) info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Robey wrote: > I have finished doing all the work and investigation (and test program > writing) > I need to do, for all of the usb aspects of my grapghic tablet Xorg Xinput > driver (well, THEY call it a driver). Yes, I know I've been owrking on it > for a > while now, but I need to move slowly for personal reasons. I can see that, > for > very up to date modules, Xorg wants to have hotplugging to work in their input > drivers. My work contemplates using the existing FreeBSD devices (my test > program uses uhid very nicely). So, I was wondering if anyone knows of any > sort > of software working in FreeBSD that doesn hotplugging (using dbus would be the > way that Xorg contemplates), then could you tell me what it is, so I can look > at it? > > I've already read up on dbus; it seems to be a messaging thing, so I just want > to see some example of how dbus would see use in FreeBSD. I figure, since the > devices I'm working on are quite inexpensive (about 60 bucks for a 8" by 6" > model), it might just turn out to be popular, if I do a really good job of > this. > That's why I want to cross every T, dot every I. I was going ahead and > adapting my test program to the Xinput example I have, when I realized I need > the hotplugging feature. Replying to my own mail, I realize I've worded this badly ... what I meant is, does any part of FreeBSD's base make any use of Hal's (the hardware abstraction layer) API? If it does, and you could tell me where that is (because I can't find it myself) then I could find the sourvce code and read it myself, so you don't need to give me some big tutorial, just point it out if you're aware of it. I said "where that it", I mean, just give me the name, I can find out where with the name in hand, obviously. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVAh/z62J6PPcoOkRAkDdAJ46GT/AOpp36nGoYj7z7MLYFFOYGwCfQ1ir zjFfI55ekunrN6qWSCTFNQ4= =J/My -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD hotplugging (Hal) info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Konrad Jankowski wrote: >> Replying to my own mail, I realize I've worded this badly ... what I meant >> is, >> does any part of FreeBSD's base make any use of Hal's (the hardware >> abstraction >> layer) API? If it does, and you could tell me where that is (because I can't > > Base definitely doesn't use it. > All you can find in base is devd. Well, good news and bad. Dropping the bad news first, I can't grep for hal or dbus anywhere in the devd src dir, which I think might mean it's not a direct user or propagator of hal. OTOH, devd's man page lists devctl, which seems mightily interesting, and could extremely likely be adapted into reporting to hal directly. My immediate worry is something I picked up from the devctl man page, that it is meant for a single reader. Does that mean that I am somehow prevented from sharing it to both devd (or devfs) AND hal, both? Or, do I manually (well, via script) create an extra devctl node? Or, maybe, am I knocking on the door of the wrong mailing list? Please let me know, my stubborn streak has seen me too close to the ending of this driver of mine to consider stopping now, I just MUST answer this last feature worry of mine. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVm1jz62J6PPcoOkRArQbAJ9G+Ql78K7LWJ1vbKB7TWqAfRtBwgCgjQgw z+AP1pYbvAgmBrdqBXvMRbg= =7eon -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD hotplugging (Hal) info
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander Leidinger wrote: > Quoting Chuck Robey <[EMAIL PROTECTED]> (from Mon, 16 Jun 2008 09:40:51 > -0400): > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Konrad Jankowski wrote: >>>> Replying to my own mail, I realize I've worded this badly ... what I >>>> meant is, >>>> does any part of FreeBSD's base make any use of Hal's (the hardware >>>> abstraction >>>> layer) API? If it does, and you could tell me where that is >>>> (because I can't >>> >>> Base definitely doesn't use it. >>> All you can find in base is devd. >> >> Well, good news and bad. Dropping the bad news first, I can't grep >> for hal or >> dbus anywhere in the devd src dir, which I think might mean it's not a >> direct >> user or propagator of hal. OTOH, devd's man page lists devctl, which >> seems >> mightily interesting, and could extremely likely be adapted into >> reporting to >> hal directly. > > devctl is reporting to devd. There's no relationship to HAL. > >> My immediate worry is something I picked up from the devctl man page, >> that it is >> meant for a single reader. Does that mean that I am somehow prevented >> from >> sharing it to both devd (or devfs) AND hal, both? Or, do I manually >> (well, via >> script) create an extra devctl node? Or, maybe, am I knocking on the >> door of >> the wrong mailing list? > > You can let devd issue commands in arrival/departure. You missed the point, which is, because I am writing an Xorg Xinput driver, I MUST use hal. I *can* use devd or devfs, if and only if I also use the hal interface. I just found out about lshal, so I was able to prove that hal is aware of all the usb devices, I just need some way to prove that hal knows this info in real-time. So far, using a dbus tool, I can't see where hal is broadcasting about new usb devices, even things that show up in /var/log/messages on time. I need to see how hal finds out about it's devices, and either prove to myself that it knows this in realtime, or add it. That's why I was interested in devctl, because it seems like the ideal method to find out about new devices, and use that info to give it to dbus. Maybe I could write some devfs or devd script, maybe one in python (there's a Python interface to dbus) to tell hal about new devices, but that would be doing it secondhand, I'd far rather get it directly from devctl. That's why I asked about the man p[age comment about devctl talking only to devd, I'd like to change that. Maybe I'll find out who wrote that, and grill that guy. > >> Please let me know, my stubborn streak has seen me too close to the >> ending of >> this driver of mine to consider stopping now, I just MUST answer this >> last >> feature worry of mine. > > Ask on gnome@ about dbus, and on x11@ about the X11 HAL stuff. > > Bye, > Alexander. > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVqxsz62J6PPcoOkRAukvAJ9pmTL3Q0rKiCyEC57MclDDEUFVlQCgkfto KJbQORD0H/ZGuipQCm4jdT8= =4hI6 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Decent 3D acceleration in 64bit mode?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Meyer wrote: > On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" <[EMAIL PROTECTED]> > wrote: > >> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking <[EMAIL PROTECTED]> >> wrote: >>> Given that Nvidia aren't offering a driver for their cards for 64bit >>> FreeBSD, is anyone else having success using another (preferably >>> PCI-E) card with 3D acceleration? >> I'd love to be told I'm wrong, but my understanding is that the issues >> blocking the nvidia driver would also effectively block a driver for which >> we had the source. > > Is there an open source driver with good 3D acceleration? > >http://enigmail.mozdev.org iD8DBQFIWtFsz62J6PPcoOkRAgGYAJ0R8Clur5S73FB7AV6rFGGyVyQLvgCgoAU+ pZYObPvyBBb22rU0SHVBPCk= =2KHm -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Decent 3D acceleration in 64bit mode?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Robey wrote: > Mike Meyer wrote: >> On Thu, 19 Jun 2008 14:00:42 -0400 "Zaphod Beeblebrox" <[EMAIL PROTECTED]> >> wrote: > >>> On Wed, Jun 18, 2008 at 8:13 AM, Stephen Hocking <[EMAIL PROTECTED]> >>> wrote: >>>> Given that Nvidia aren't offering a driver for their cards for 64bit >>>> FreeBSD, is anyone else having success using another (preferably >>>> PCI-E) card with 3D acceleration? >>> I'd love to be told I'm wrong, but my understanding is that the issues >>> blocking the nvidia driver would also effectively block a driver for which >>> we had the source. >> Is there an open source driver with good 3D acceleration? > >> > Could I ask, does anyone here know the reason (even in general) that the > Nvidia > driver isn't working on the i386? CRAP I meant AMD64. I'm beyond hope. > > I mean, I was wondering what might be my next project ... I have the > machinery, > and the source code is totally available, it's not a matter of Nvidia giving > out > a binary-only module, right? So, is anything more known? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIWtKAz62J6PPcoOkRAqs5AJ9dR9oVygdQwhbTfi9Zn15HmTnvkwCeNWuY oD74ln11Ryu6Ebr4mubBwfA= =h7p6 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Laptop suggestions?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zaphod Beeblebrox wrote: > On Fri, Jul 25, 2008 at 1:35 PM, Razmig K <[EMAIL PROTECTED]> wrote: > >> How about Dell models which come with Ubuntu preinstalled? (Inspiron 1525N >> and 1420N, XPS M1330). Don't they have higher chances of running FreeBSD >> smoothly? A quick glance over the hardware notes of 7.0-RELEASE and some >> googling around show that wireless, video and audio are supported. >> > > One problem with most of the Dell offerings is that they use the NVidia > video chipset. Now this is a plus if you're into playing a few games, but > it sucks if you're running FreeBSD. There is a problem is you're running the AMD64 chipsets, but I'm running a quad core processor here, and my Nvidia card (8600GTS) with it's compiled Nvidia driver works just fine. One of the original requests was for >> 4G RAM. The NVidia binary driver only works on IA32, not AMD64 (and the > opensource driver sucks at even 2D), so your RAM is practically limited to > around 3.5G (depending on a few things). I also havn't seen very many > laptops advertising >4G yet (4G, but not more than 4G). > > Personally, I have the XPS-1730. Largely I tolerate the slow binary driver > for AMD64. I use IA32 when I need wine, but my use of ZFS (the 1730 has an > option for 2 hard drives) seems to eat up kernel memory until wine can't > start pretty quickly. The opensource driver does work and supports nice > things like DPMS it's just that the 2D acceleration feels very lacking > and it also can't do things like scale a movie at full frame rate. This > means that I tend to reboot into windoze for entertainment ... since I can't > generally use IA32 mode productively anyways. > > Other than the video and the fact that I've never seen a Dell suspend > successfully under FreeBSD, The laptop is well supported. The PCI express > slots and their contents (USB or PCI) show up fine. Even the EVDO broadband > modem is fairly easy to suppport. I think the only feature without any > support is the SD card reader. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiKSCYACgkQz62J6PPcoOmb/ACdGHfxU4Rpt9k9UaYYc6X2UpFD TQkAnA0hlM1UwzDJMUpAe72zJIGQ0vBN =95ZS -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
read with timeout ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have my head lost in a code problem. I just hit a point where I need to do a read from an fd, but I need to associate it with a timeout, on the order of 1 second, something like that. I had the feeling that there's a function in FreeBSD's libc that makes that simple, but I forget the function name. If anyone can remember something like what I'm talking about, I sure would appreciate a function name. I can figure out how it works, if I could only dredge up that name. I just wouldn't like to come up with 4 pounds of code where it ought to be done with a 1-liner. If you're curious, I'm still working on that tablet driver for FreeBSD. It's taken me this long to figure out that Xorg driver code. The Xorg folks have been helpful, but basically, there's almost no docs, nearly no comments, and testing a driver isn't the easiest thing in the world. Regardless, I'm getting really close on this, finally. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkibnQoACgkQz62J6PPcoOlIaQCdG5R0p0X/hXVYh/qkX/zK63/E y+EAn3ahlXnPGPzqSdVdhbx1YsEjT4qr =bA6Z -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: read with timeout ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Pieter de Goeje wrote: > On Friday 08 August 2008, Carlos A. M. dos Santos wrote: >> On Thu, Aug 7, 2008 at 10:14 PM, Nate Eldredge <[EMAIL PROTECTED]> > wrote: >>> On Thu, 7 Aug 2008, Chuck Robey wrote: >>>> -BEGIN PGP SIGNED MESSAGE- >>>> Hash: SHA1 >>>> >>>> I have my head lost in a code problem. I just hit a point where I need >>>> to do a >>>> read from an fd, but I need to associate it with a timeout, on the order >>>> of 1 >>>> second, something like that. I had the feeling that there's a function >>>> in FreeBSD's libc that makes that simple, but I forget the function >>>> name. If anyone can remember something like what I'm talking about, I >>>> sure would appreciate a function name. I can figure out how it works, >>>> if I could only >>>> dredge up that name. >>> man 2 select >> If the fd is a socket then you can also use setsockopt(2) to set >> SO_RCVTIMEO and check for EWOULDBLOCK (same as EAGAIN) upon read(2) or >> recv(2) errors. The net effect is the same of using select but the >> syntax is simpler, IMO. > > I think poll(2) is also simpler than select for this purpose. > It does look like that, I need to check the implementation a bit, because the name of this thing makes me really suspicious about how often it checks for an fd for being ready for a read. I know select comes right back, I was under the impression that poll didn't use signals to do this. Anyhow, I sure do appreciate the hint, that's just exactly what I was asking for. Spending the time figuring it all out, that'll actually be fun for me. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkicrC8ACgkQz62J6PPcoOmYjACfWP/IGjSvak1hLYSJwWBKkTjb 8qUAoJfSYOZcPJKMqqUb3Y1mltG51sgI =USHT -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: read with timeout ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Carlos A. M. dos Santos wrote: > On Fri, Aug 8, 2008 at 5:09 AM, Pieter de Goeje <[EMAIL PROTECTED]> wrote: >> On Friday 08 August 2008, Carlos A. M. dos Santos wrote: >>> On Thu, Aug 7, 2008 at 10:14 PM, Nate Eldredge <[EMAIL PROTECTED]> >> wrote: >>>> On Thu, 7 Aug 2008, Chuck Robey wrote: >>>>> -BEGIN PGP SIGNED MESSAGE- >>>>> Hash: SHA1 >>>>> >>>>> I have my head lost in a code problem. I just hit a point where I need >>>>> to do a >>>>> read from an fd, but I need to associate it with a timeout, on the order >>>>> of 1 >>>>> second, something like that. I had the feeling that there's a function >>>>> in FreeBSD's libc that makes that simple, but I forget the function >>>>> name. If anyone can remember something like what I'm talking about, I >>>>> sure would appreciate a function name. I can figure out how it works, >>>>> if I could only >>>>> dredge up that name. >>>> man 2 select >>> If the fd is a socket then you can also use setsockopt(2) to set >>> SO_RCVTIMEO and check for EWOULDBLOCK (same as EAGAIN) upon read(2) or >>> recv(2) errors. The net effect is the same of using select but the >>> syntax is simpler, IMO. >> I think poll(2) is also simpler than select for this purpose. > > BTW, the setsockopt(2) manual page stands that a send or receive > timeout returns with the error EWOULDBLOCK but read(2) recv(2) send(2) > and write(2) only list EAGAIN in their ERRORS section. This is > harmless on BSD and Linux because EAGAIN and EWOULDBLOCK are the same, > but may sound confusing for people porting from/to System V. On HP-UX, > for instance, recv(2) lists both EAGAIN and EWOULDBLOCK. > > The setsockopt man page should be improved in order to explain > standards conformance and porting issues. I volunteer to do it but the > changes must be reviewed by a native English speaker. > Carlos, lets not go off on the socket trip for me... while I personally enjoy such a email, I have to admit my own needs fall more into a plain-jame serial line, nothing a socket-oriented thing could help me with. However, if you want to discuss this just fo the fun of it, oh please, by all means do carry on! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkicrPkACgkQz62J6PPcoOmJowCfWPt1jHY4Gx0kOAQedVATHYDd BGYAoJe6JYuskZZe85AA63sgRBG1VGF0 =dNTn -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
startup options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering if it was possible, with a machine that has about 2 year old dual AMD64 processors and an up-to-date AMI BIOS, to get the machine to be able to start up from a power shutdown, after some sort of a network signal? If it might be possible, could you maybe put me onto the path of whatever info there might be on that subject? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkil6/YACgkQz62J6PPcoOk0wQCfTxUcKLOdhsOUvpwVNYOw74Ly V04AoISC3BGQsnlJeCUsdSc/VxK+K0D6 =FsXX -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
keyboard questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have gotten my project, which was to make an Xorg driver for my ultra-cheapy UC-Logic graphic tablet working to a great extent, including scaling the cursor movement both with and without the optional function key areas that rim the tablet area. So, my next job is to figure out how, on FreeBSD, should I configure and dispatch these things. They AREN'T to be limited, at all, to being function keys, I want them even to include the possibility of kicking off programs (or maybe shell scripts?). So, knowing absolutely zero about interfacing keyboards on FreeBSD, could I get a VERY minimal description, enough so that I could begin reading all of the man pages (and include files) involved, and get this last part going? Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjELsUACgkQz62J6PPcoOnOnQCfWE6Sr7x6gaN8C28HO5/a7tOP JCIAn2abiL5Q/whTM+bHCx3E0FWWpHF1 =JDfG -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
UCLogic tablets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've just finished the first version of a Xorg driver for the UCLogic family of graphic tablets. It may well work for other tablets, if I could see what folks have, so I could program the names in. Anyhow, the UCLogic tablets are *very* widely OEMed, so I couldn't even begin to guess the tablet name you have, but if it USB-probes as having a Vendor name of UCLogic, then I think this might work for you. Anyone who might want to try it, you might mail me, I'd kinda like to beta-test it before I generally release it. I also did up a manual page. Write me if you're interested. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmcpkACgkQz62J6PPcoOnd1QCdHnPhB31IIyTnlk6Ii8E3eEh/ oV4AoJEn4+jA/wJjw9o+5OGsQeohALYS =RmnH -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: UCLogic tablets
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck Robey wrote: > I've just finished the first version of a Xorg driver for the UCLogic family > of > graphic tablets. It may well work for other tablets, if I could see what > folks > have, so I could program the names in. > > Anyhow, the UCLogic tablets are *very* widely OEMed, so I couldn't even begin > to > guess the tablet name you have, but if it USB-probes as having a Vendor name > of > UCLogic, then I think this might work for you. Anyone who might want to try > it, > you might mail me, I'd kinda like to beta-test it before I generally release > it. > > I also did up a manual page. Write me if you're interested. > > Thanks I forgot to add, the reason for posting here is because I wrote it specifically (at first) for FreeBSD. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjmcvcACgkQz62J6PPcoOmRRQCfed2tnNxlN6zI+2me/ubbDRpJ jzoAnRlCdVJW/4LsYB+uMhlAEie52FNs =u4bq -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
touch screen recommendation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering if anyone here had a recommendation for a touch screen, specifically to run on FreeBSD? Any user report? Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjpCQQACgkQz62J6PPcoOl5MwCeKJAkbeQ/+GGpWX/b2CAV/F8J c1sAn0d7tXct21/SfdAYY2otfvFVuqK2 =XMw8 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
indicating a debug image
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering, for FreeBSD images, is there a symbol that one could look for, to indicate if image had debug symbols? I know you could destroy that by just stripping, I just wanted to know if there is any way to definitely tell, short of firing up gdb and looking for info. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkj3zV4ACgkQz62J6PPcoOn7FQCfSmBRRDLHJE71x/86IF+ELGKi beEAoJLb/2SpNhg9YGmaioGkSCcySVlw =4AbD -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: usinig cvs diff to make a patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aryeh M. Friedman wrote: > I use a local cvs repo and I have modified a port and which to submit an > update for it how do I generate a patch file with cvs (cvs diff seems to > give a unusable format)? > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" cvs diff -u gives the unified format (or cvs diff -c for context, get the pattern?) Or, copying from the web page http://www.eyrie.org/~eagle/notes/cvs/basic-usage.html, which shows how to use the ~/.cvsrc file to make common cvs commands default the way you want them to, you could put into that file the line "diff -u" so it always gives you the unified diff format, which just happens to be the easiest for humans to read, and the format specified in FreeBSD (hint, hint). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmIm9EACgkQz62J6PPcoOnRlQCeIT8vsLZ6LI764WOaTQy72ym4 Tp0AoJ43TIQYsGFz8YYD2ChhMSUU0Wpc =ta5/ -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
x11 status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I was wondering, I've lost track of the status of XFree86 on FreeBSD.or really, at all. It looks like all of the Xfree86 servers have been removed from ports. I was looking on the www.Xfree86.org website, and from what I see, it apparently still is generating releases. Also, I downloaded the latest cvs image from Xfree86, and it built FAR easier that xorg, far faster, far simpler to configure ... but when I look into FreeBSD-ports, the few ports which still have the Xfree86 name, they're really cheating (talking about the drivers), they seem to be really xorg drivers, just haven't had their names fixed. No servers for Xfree86 exist in ports anymore, even though it seems trivial to build. Why is that? Is XFree86 not getting any fixes? It seems that their version 4.8.0 is recent, so I'm confused. I just wanted to know if it's missing from ports for some reason, or only because someone wanted it removed? It couldn't be because of a massive prejudice for configure-based ports, is it? (I hope not). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmkue0ACgkQz62J6PPcoOkgOQCfS+bPR3zcTvckuTtY0fxMBMTT OwsAnjVrFGOLjWhJjDbror4xgzHqjmrV =nFWV -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
howto configure FreeBSD's hal?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to find anything on how to set up hal on FreeBSD. I hope it's because I'm being lousy at searching, not that there just isn't anything on the subject. I think all I want is to set up my Logitech wireless PS/2 (via a USB to PS/2 converter) mouse, and a PS/2 keyboard. I have a RAID/1 (via a twa driver), I don't know if that affects my hal or not. I honestly would far arther do my own configuration, if I could only find anything written up on how to accomplish this on FreeBSD (current). Sure would appreciate a pointer to this. I have the idea that anything I could find would be written for Linux, which wouldn't be terribly correct for FreeBSD's device setup, am I right? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmsP94ACgkQz62J6PPcoOlnCQCcCOTg3iBny8uIbWDLIZJvASfI v+MAnjtujaWT9pUawJVmJFKVMU2M5qKJ =relA -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
dbus causing my cvsup to fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This one completely mystifies me. I have a little script I use to cvsup, cvs update, and rebuild my system, and it's been hitting failures about once a month over the last 6 months. The failures are all fairly alike: cvsup fails to apply a delta to one of the text files in /home/ncvs/usr/ports (not the subdirs, things like UPDATING only). Generally I don't notice this until hours later, when I notice that my cvs update of that file failed, and I've been fixing it by deleting the affected file in my /home/ncvs, and re-running my script. Just now, I happened to run it while I was watching, and I caught this coming from my messages, it's obviously from the same processes (my machine is named "april"): Mar 22 17:03:32 april dbus-daemon: Would reject message, 1 matched rules; type="method_call", sender=":1.59" (uid=1001 pid=42493 comm=") interface="org.freedesktop.DBus.Introspectable" member="Introspect" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=1202 comm=")) I lost the actual error message, but I recall that the 1.59 was part of the string defining the delta. The rest of it I'm blaming on dbus due to the very coincidental timing, exactly the same as the error. I wish I'd kept the original error, but it's gone now, it didn't go into messages. So, somehow, dbus is causing this, but I'm not on particularly good terms with dbus & hal, so I can't tell where to go to start fixing this. Anyone get anything from this error message? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknGr9YACgkQz62J6PPcoOkabQCdEE6Icqcs13cZpc8W8OkPgJ7B RaAAoIIepuLb6eXAurn/iGicQNNXqCVl =rHj3 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
the web site
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I just had to see if I could locate if there was a gnome project page by looking at the FreeBSD web pages. Why don't you try that yourself? I'll tell you, it's really FAR from being obvious. I'm just saying, even if folks don't want to change the web page, then a TOC-like section should be added near the bottom, to make navigation easier. I've tried my own hand at the web page design. I think I only proved to myself that I'm no artist, but it wouldn't maek things TOO ugly just to add a section at the bottom, would it? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknP6s4ACgkQz62J6PPcoOkwzgCfXJtkN/PRNhRqvApSJCzjS6uj vW0An1yPG0wzG3d3i3njO5H3gJ2p8w9I =aBYh -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
building a gcc crosscompiler
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since the last time I built a gcc crosscompiler, the gcc folks have added in dependencies on mpfr and gmp libraries. When I first read this, I was worried that I had a chicken/egg problem, but I found that you can do with the host's version of those libraries. I found a port of gnu libmpfr, but I notice here that FreeBSD has it's own libmp, and I don't know if the 4.3.1 version of gnu gcc can use our libmp, or if I need to install the port "libgmp4" and tell the gnu gcc configure about which mp I'm using. So, if you know if I can use FreeBSD's libmp, or if I need to build the ports libgmp4, please let me know. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkndT6YACgkQz62J6PPcoOmsiQCff6qjZ46dxn8P+5c19gAP2dip 3YsAnj2/sy3nhZzk1TWz1Rfv7PQ2Uw5f =5iqj -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Collecting waiting statistics (simulation question)
On Mon, 14 Aug 2000, Jeff Rhyason wrote: > > A lot of sysctls implement some sort of statistics mechanism > > such as counters. Do a 'sysctl -a' and you'll see various > > sysctls being used for counters/stats. > > Aah. This isn't quite what I lust for: Is it possible to get a *log* of > allocation requests rather than aggregate sums or averages? The reason is > so I can calculate the distribution of the data. For example: the kind of > information I would like to have from kern_malloc for each invocation is: > - time of the allocation > - size > - time spent in asleep > - return value > The same thing can be done with kern_free and from there the time the > memory was used can be calculated. So write it. It wouldn't be terribly difficult. I don't think it'd be terribly popular (so you won't be able to talk someone here into doing it for you) but you could grab an idea for the communications & logging from syslog (using a daemon & a socket) and just instrument the right parts of the kernel to write to the socket. You'd have to write the daemon & write a bit of code in the kernel. It would be a reasonably simple project. Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED]| electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to support adaptec 29160 ?
On Mon, 14 Aug 2000, Kazennov Vladimir wrote: > Hello ALL! > Please, give me some info about support adaptec 29160 with FreeBSD > Kernel during installation doesn't recognise this adapter Works fine for me, just using the ahc driver (endless thanks to Justin Gibbs!) I have a dualbussed 7895 controller on my motherboard, so the 29160 became my ahc2. I only have one of the my drives up yet, but my hints file looks like: hint.da.3.at="scbus2" hint.da.3.target="0" hint.da.4.at="scbus2" hint.da.4.target="1" (scbus0 & 1 already used up with the 7895). The config file just needs the single "device ahc", no count required. The dmesg so far (with only one of my two drives up): ahc2: port 0xf000-0xf0ff mem 0xfecfd000-0x da3 at ahc2 bus 0 target 6 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit) da3: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) Bonnie tells me: ---Sequential Output ---Sequential Input-- --Random-- -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks--- MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU 100 16798 98.2 27256 63.6 10974 35.3 15611 99.2 29266 45.0 366.9 7.3 ---- Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED]| electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Collecting waiting statistics (simulation question)
On Mon, 14 Aug 2000, Jeff Rhyason wrote: > > So write it. It wouldn't be terribly difficult. I don't think it'd be > > terribly popular (so you won't be able to talk someone here into doing > > it for you) but you could grab an idea for the communications & logging > > from syslog (using a daemon & a socket) and just instrument the right > > parts of the kernel to write to the socket. You'd have to write the > > daemon & write a bit of code in the kernel. It would be a reasonably > > simple project. > > OK I will get started. Can I hassle you for help? Occaisonally, but you'd do better hitting this list in general. I'm on a new job and I'm giving it a LOT of hours; you might wait a week for me to find time to generate an answer. It depends on your questions, too. If you demonstrate by your question's topic and focus that you've made a *hard* effort to answer it on yourself, *loads* of folks will help. If it looks like just another person looking for a free ride (and there's so many of those that we get a bit defensive) then you wouldn't expect too much. Chuck Robey | Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED]| electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
handling pdfs?
I need to read about 4 tons of some really sparse pdf specs. I also have a rather inconvenient throwback: I feel hugely more at home-reading documents in paper. What I'd kind of like to do would be able to perform cut'n'paste among different pdfs, 5 pages here, 10 pages there, until I put together maybe 100-200 pages, and sit back and read it. What I can't do is print just a few pages out of several 800-plus page specs, and perform paper cut'n'pasting. Is there some sort of util that will allow me to do cut'n'pasting among different pdfs, or at the very least, only to print certain ranges out of pdf docs, so I could do paper-wise cut'n'paste? An all-electronic solution would be best, but I'd take whatever offered. Thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status of kernel threads.
On Thu, 23 Dec 1999, scott wrote: > I've found > > http://www.cornfed.com/pk > > looks weird, but says it will do kernel threads for FreeBSD. I looked to see this, but didn't. It does say it has a "BSD" license, and it says it *cross*builds* under FreeBSD (and, for that matter, Linux also), but I see nowhere that it makes a FreeBSD kernel. It doesn't even say if it supports a filesystem. I'm downloading the code, but it sure doesn't say more on the website. -------- Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Terminal colors
On Sun, 26 Dec 1999, Alexey Zelkin wrote: > hi, > > AND> Say I want to change the man colors when I read mans at the console. More > AND> precisely, I don't like that underlined text shows up as reversed (black > AND> letter on while(grey,7) backround). How (and where) do I need to say that > AND> I want, say, yellow on black instead of reversed when displaying > AND> underlined-supposed-to-be text. Any help is greatly appreciated. > > For supported escape sequences (sequences used to change colors) you can > read screen(4) manpage. > > Then read termcap(5) manpage. It will describe you termcap file structure. > Pay espessial attention for `md' (bold mode on) and `so' (standout mode on) > directives. > > Contact me directly if you need more comments. And don't forget all the many different flags to xterm, you can control a *lot* that way, if you're in X. > > Chuck Robey| Interests include C programming, Electronics, 213 Lakeside Dr. Apt. T-1 | communications, and signal processing. Greenbelt, MD 20770| I run picnic.mat.net: FreeBSD-current(i386) and (301) 220-2114 | jaunt.mat.net : FreeBSD-current(Alpha) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
On Tue, 4 Jan 2000, Ed Hall wrote: > : I have just upgraded my system to -current w/egcs 2.95.2 and I have > : several problems with it, especially when using optimizations (-O2 and > : such) > > Have you reported those problems to <[EMAIL PROTECTED]>? Bugs aren't > very likely to get fixed if no one reports them. > > As for free alternatives--I don't think there are any, especially if > you are looking for something "better" than the current GCC. The > various free C compilers I've seen over the years have been little > better than toys. There are some, but it's very difficult to replace the system compiler. Look in ports/devel. Your given reason, tho, doesn't make too much sense ... first thing, the options have changed, and -O2 doesn't work. I know you don't mean this, but it sounds like you're complaining that you can't use -O2, not that you can't get a specified kind of optimization (which can be addressed). The gcc we have is the best choice presently, else we wouldn't be using it. I want to make it clear, so I'm going to use an extreme example of what I mean, please don't take it wrong; I could very easily give you a small shell wrapper over gcc, that would make -O2 work (it would throw the option away). You obviously don't want that, but it's the only basis of the problem you display. What specific kind of optimization are you looking for? If you ask that, probably your problem can be more directly addressed using our present compiler. Chuck Robey| Interests include C & Java programming, New Year's Resolution: I | electronics, communications, and will not sphroxify gullible| signal processing. people into looking up | I run picnic.mat.net: FreeBSD-current(i386) and fictitious words in the| jaunt.mat.net : FreeBSD-current(Alpha)| dictionary.| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [OFFTOPIC] alt. C compiler
On Wed, 5 Jan 2000, Patryk Zadarnowski wrote: > > Hi, > > > > is there any alternative (non-commercial) C compiler to use, or is gcc the > > best? > > > > I have just upgraded my system to -current w/egcs 2.95.2 and I have > > several problems with it, especially when using optimizations (-O2 and > > such) > > > > ok I know there's the good old gcc 2.7.2.3 but a good BSD-licensed > > compiler would be nice =) > > Check out TenDRA in the ports tree. Unfortunately, most ppl tend to > use GCC extensions a lot, so you won't be able to replace gcc, but > TenDRA certainly is a solid alternative. With the understanding that using Tendra just for the kernel will be painful, but (if you're determined) doable. If you want it for building world, you better make prior reservations at the local mental health clinic, because YOU WILL NEED IT before you get that done. > > Pat. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Chuck Robey| Interests include C & Java programming, New Year's Resolution: I | electronics, communications, and will not sphroxify gullible| signal processing. people into looking up | I run picnic.mat.net: FreeBSD-current(i386) and fictitious words in the| jaunt.mat.net : FreeBSD-current(Alpha)| dictionary.| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #730
On Tue, 18 Jan 2000 [EMAIL PROTECTED] wrote: > Where is a good place for me to place an advertisement for "intrusion > testers"? We are in no way connected with any law enforcement or Government > agency. We are a computer investigations firm in Florida and have an urgent > need for some of these individuals. We are a global company with a D&N > number if you would like to check us out. > > Kellie Carlisle, President > Advanced Computer Investigations and Services > 407.566.0504 or 407.973-4939 I think [EMAIL PROTECTED] is the correct venue for offers like that. > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > ---- Chuck Robey| Interests include C & Java programming, New Year's Resolution: I | electronics, communications, and will not sphroxify gullible| signal processing. people into looking up | I run picnic.mat.net: FreeBSD-current(i386) and fictitious words in the| jaunt.mat.net : FreeBSD-current(Alpha)| dictionary.| To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
On Sun, 23 Jan 2000, Mike Smith wrote: > > I can't agree with Mike Smith that reading the code is adequate. It > > certainly doesn't apply to newcomers, but it doesn't even apply to > > seasoned hackers like Mike: the BSD style doesn't provide for adequate > > comments, and so what you see from the code is mainly tactics, not > > strategy. > > You miss my point; you don't want to be writing a driver until you know > what you're doing. Documentation on an OS' driver interface won't teach > you that; it's something that's really only ever gleaned from experience. The problem is, you can't even find what the interfaces are. Reading the code isn't very useful if you can't even find the right place to start from. At least the interface points could be listed, so that someone would know where to begin. > > Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Learning the FreeBSD Kernel
On Mon, 24 Jan 2000, William A. Maniatty wrote: > Both Chuck Robey and Mike Smith have some points, but that won't > stop me from giving my opinion :-). Mike is correct that experience is > key to being a solid systems software developer, who writes device drivers. > Now the next question is how can someone get experience? By developing > systems software (which by the way they should only do if they have > experience at it :-)). > > Traditionally there are two approaches: > 1) Have a friend available and bug them for help when you get stuck :-) > 2) Read the documentation. > 3) Read the code and lose a whole lot of productivity without certainty > of figuring it out on your own. > 4) Dismiss the whole problem as unmanageable and throw your > weight behind a more productive project. I know where Mike's coming from. Wait until the next guy posts on the list "I don't really know how to program, but please tell what 'C' is, and how to write a device driver". We had a pretty nasty flamewar over that maybe (I think) 9 months ago, and it still hurts folks, to be accused of conceit, when the guy was asking a grossly unanswerable question, and wouldn't believe it couldn't be boiled down to a 4 paragraph "device drivers for dummies" thing. Mike wants to avoid dealing with a horde of folks like that. I can't really blame Mike, it's impossible to make people understand that you can't boil everything down to a 30 second sound bite. BUT I still wish there was a map to interfaces. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: compiler errors (fwd)
On Wed, 26 Jan 2000, f.johan.beisser wrote: > ok, here's the scenario. I didn't install any ports until I went to do the > `make buildworld`, when I installed cvsup to get the source updates. > > full binary+sources install from the 14 Jan 2000 snapshot > AMD K6-2 450MHz (corroborated by dmesg output) > c. 8 gig Seagate IDE HD > 64 megs RAM > cheap motherboard with everything built in, and one PCI slot > > here is the final lines of output from trying to compile the GENERIC kernel > (doing a `/usr/sbin/config GENERIC`): > --- > -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 > ../../netinet/in.c > cc: Internal compiler error: program cc1 got fatal signal 11 > *** Error code 1 > cc: Internal compiler error: program cc1 got fatal signal 11 Signal 11 is usually an artifact of bad hardware, like bad RAM. You don't state what version of FreeBSD he's running, either. Did you know that, if he's running a system older than about 3 months ago, he CAN'T buildworld unless he installs a new kernel first? ---- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kern/13644
On Thu, 27 Jan 2000, Oliver Fromme wrote: > Warner Losh <[EMAIL PROTECTED]> wrote in list.freebsd-hackers: > > In message <[EMAIL PROTECTED]> "Jonathan M. Bresler" >writes: > > : The terminology is very simple. Anyone that can cope with > > : either vi or emacs can learn: > > : > > : NUL: an ascii character (0x00) > > : NIL: a pointer at the end of the line > > : NULL pointer: used in C to refer to NIL. > > : not to be confused with NUL. > > > > But NIL is not a poitner at the end of the line in gnu emacs. It is > > the empty list. > > Traditionally, NIL is the last element in a list, which marks > the end of the list. NIL is the abbreviation of "not in list". > (I'm not familiar with elisp, though.) Now that's the definition *I* learned. Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
box seizing up
I was trying to take a box that was running an old version of BSDi and move it to FreeBSD current. My first try was with the first CD I could find, which was 3.2 (I have later ones, they're just deeper in the pile than I cared to look for). The box, after install, was kinda unstable, given to sudden lockups, and the driver for the DNET card with the AX8841 in it would lock right up when I tried it. On reboot, with the older unfixed fsck, it would take multiple reboots to recover from the lockups, so I shuttled (via floppy) a kernel compiled under current (with the dc0 driver) and /bin and /sbin to the new machine. Now, excepting network, it's stable as a rock, but when I try use the network card, it locks up about 1 second after the ifconfig. Let me give more details. The dmesg part that's pertinent: dc0: port 0x6100-0x617f mem 0xf0201000-0xf020107f irq 12 at device 19.0 on pci0 dc0: Ethernet address: 00:80:ad:41:4a:95 miibus0: on dc0 amphy0: on miibus0 amphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I added a little reformatting, my mailer bends lines. Anyhow, doing a ifconfig -a gets me an entry for the dc0, so I tried setting the inet and netmask. The next second, each and every time (I've done this 4 times) it locks up solid. Before I do this, kldstat shows only the kernel loaded, and my /modules comes from the same current as the kernel (I never run kernel and user out of sync anyhow), so an out-of-sync kld being loaded shouldn't, I think, cause a lockup. Anyone know what the dmesg line that reads "amphy0" means? I only have ONE network card in there, that's an absolute fact. The machine's pretty bare, just scsi, vga, and network card (the cdrom's scsi). One scsi disk, one floppy. And problems. -------- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: porting linux app. Syscalls
On Thu, 3 Feb 2000, Marco van de Voort wrote: > --- not related to the other 3 > 4. In the rare event that I get it finished this week; The ports howto doesn't seems >to > apply to bootstrapping stuff. (It assumes the apps are gcc based or created by > a gcc compiled app (like perl). > > Where does such an app fit into the BSD project? > > - several megs of Pascal source (entire project + sideprojects + texdocs is 25 MB >source) > - gmake makefiles. > - binary required to start the compile(either native FBSD or linux) > > . (compiling the bsd version with the linux > compiler is also possible I think, if a linux binary can create an ordinary FBSD > binary) This is just answering the last point. The modula-3 port is about the same size as yours, and it bootstraps, but (like you said) it does it from C. The lang/objc port *used* to require a binary-only bootstrap image, only. What I did there was to move the linux image home, use it to bootstrap a FreeBSD image, stored that on my home page, and made the port fetch it as one of the distfiles. In building the port, it just referenced the FreeBSD-native binary boot image to bootstrap itself, but it did build a full image of itself from that. Objc doesn't need that anymore (it has a C boot now) but you could take that approach. It's in the archives, probably version 1.5 of the Makefile, from October 97. > > > > Marco van de Voort ([EMAIL PROTECTED]) > <http://www.stack.nl/~marcov/xtdlib.htm> > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
MAKEOBJDIR
This is the kind of thing I normally look into the mailing list archives for, but since they're down now ... Does anyone know where there's a good explanation of how make uses MAKEOBJDIR and MAKEOBJDIRPREFIX? They're listed as being respected by make in the man page, but it doesn't say why. I'm trying to understand how it's used in older systems and current systems, and not able to follow it yet. Something is done via bsd.obj.mk that I can't see (because of make's special relationship with those two). Thanks. ---- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: MAKEOBJDIR
On Fri, 11 Feb 2000, Chuck Robey wrote: > This is the kind of thing I normally look into the mailing list archives > for, but since they're down now ... > > Does anyone know where there's a good explanation of how make uses > MAKEOBJDIR and MAKEOBJDIRPREFIX? They're listed as being respected by > make in the man page, but it doesn't say why. I'm trying to understand > how it's used in older systems and current systems, and not able to follow > it yet. Something is done via bsd.obj.mk that I can't see (because of > make's special relationship with those two). Replying to my own message... I was working on an old 2.2.2 system, when I got home and checked the current man pages, there it was, nice as you please. Sorry to bother folks. -------- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shell Code...
On Thu, 24 Feb 2000, Michael Kyle wrote: > > Hi does anyone have shellcode for freebsd. If not, > I'll disassemble execve, but I'd rather just pick > it up from the group. When the source is freely available, why do you need to disassemble? Besides that, what do you mean by shell code? -------- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idea: official hardware manufacturer blacklist - let's wake emup!
On Sun, 27 Feb 2000, Michael Bacarella wrote: > > I love the idea myself, but I have no power over FreeBSD :( You may not like the shape of the world, but I don't think getting publicly nasty about it is going to have any positive effect. It WILL have a negative effect, as FreeBSD would gather the reputation of very vindictive; it's even very likely that, somewhere along that road, a lawsuit over some wording would arise. You just can't get what you want all the time. ---- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: idea: official hardware manufacturer blacklist - let's wake emup!
On Mon, 28 Feb 2000, Karsten W. Rohrbach wrote: > hm > > i mean, do the hardware people want their stuff supported or not? that's > the main question > some seem to choose the NOT. Hmmm. You're saying any one who disagrees with you chooses not to have their stuff supported; "if you don't agree with me, you must be stupid", right? Your approach probably will work, some percent of the time. I maintain that it won't show any real gain over trying to portray ourselves as professionals, and it will definitely hurt our credibility. Some vendors don't read anything sent to them, no matter what it is. Of those that are at least subject to *some* kind of influence, they will just kill-file whining and complaining. Well reasoned pleas (that clearly show that we're not Windows-folks, we don't want their code, just an interface) is *far* more likely to be read, and not make us look so vindictive. ---- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
On Fri, 18 Feb 2000, Bruce Gingery wrote: > So I'll leave it up to you. There should be info at least in > a FAQ somewhere that indicates that bad RAM is not something > that can be ruled out until tested adequately, and perhaps a > checklist of symptoms that (virtually) ALWAYS indicate bad RAM, > or at least should make it suspect. It's *precisely* that attitude that makes up all immediately and completely against recommending any memory tester whatsoever. You apparently didn't read what Jordan told you closely enough to catch the main point: There is *no possible software method* of catching memory errors, with more than a 25% chance of really catching errors! There is NO "checklist of symptoms that (virtually) ALWAYS indicate bad RAM". Jordan wrote you what appears to be good advice. Like many who've posted before you, you can't believe that all the memory test programs you can purchase are all pretty much useless (only catching an extremely small set of huge memory faults). Your first post spoke of getting the memory failure "although it had supposedly passed the BIOS memory tests". BIOS checks only the existence of memory, not it's functionality. The closest you can come to in-home memory checks *IS* memory swapping, and disabling BIOS. Advocating other advice in FAQs means only giving out definitely bad advice. Your own experience, in having a memory tester find the problem, is exceptional, most folks wouldn't have even found it that way. What do you tell to users, when they claim they haven't any memory problem, because they already *used* your recommended memory tester? After all, the memory test program is in your FAQ, it's gotta mean something, right? Folks won't believe you when you tell them it's very nearly worthless. The mere existence of recommendations of memory testers, no matter how you wrap them in warnings, is enough to make users certain that you're lying when you say that they haven't even reduced the odds of a memory fault, in doing their software memory tests. Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: DeCSS
On Mon, 21 Feb 2000, Chris Costello wrote: > On Monday, February 21, 2000, Bill Fumerola wrote: > > You're one of those people who follows instructions, are you? > >You're one of those people who out words, aren't you? :) Hey! I got some cream pies, you two want to go at it? We'll all cheer! > > ---- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
On Sun, 12 Mar 2000, Nate Williams wrote: > > >That's also why I am wasting my time slowly documenting the FreeBSD > > >internals in my spare time. > > > > "slowly" is the key word here. Real products are documented before they are > > in commercial use. > > Really? That's very different from my experience as a commercial > software developer. > > And, it's not the experience I had from using your products as well. > Documentation was as sparse as the FreeBSD documentation, but this is > typical of most projects, except for government projects which requires > truckloads of documentation. > > That's the main reason that government projects are rarely on time and > budget, and never end up with the features that are desired. They spend > all their time documenting, and no time implementing. :) You ever see those docs they write? Generally, it's an odd case of nothing actually being better than something. I did once see a company that did the docs first, and then used those docs as the design template. Any changes in the design had to be modified in the docs first, and the docs were under a version control system. That was the one and only time I ever saw that. Dennis is living on another planet than we do. And don't call the stuff that comes with consumer products docs, because they are usually written by marketing, and usually largely a work of fiction. Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?
On Fri, 10 Mar 2000, Dennis wrote: > > >I fail to see how you can read anything bad into this announcement. If > >you're really concerned, you have just as much right to the code as any > >one else, feel free to take the 4.0 code base and create your own system. > >BSDidier has a nice ring to it. > > > >Personally, I've been running FreeBSD since 1.0, and I'll be sticking > >with it for quite some time to come. > > Ever read Animal Farm? Remember that BSD/OS started out as "cheap with > source" and grew into "just another OS company". Good ideas can turn bad > very quickly. Instead of assuming that they are going to "go wrong", why not give them a chance to do it right? Everything is in place for exactly the right things to happen, I couldn't have planned it better myself, but some folks aren't happy unless they see conspiracy. When you see something wrong, you can speak up, but stop complaining about stuff that hasn't even happened yet. You could generate enough ill feelings and bad publicity to *cause yourself* the exact thing you're worried about. Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Fri, 10 Mar 2000, Oscar Bonilla wrote: > $ cp Makefile.static Makefile > $ make > cc -g -DYP -DFreeBSD -Wall -pedantic -ansi -c -I../../libc/include nss-test.c > cc -g -nostdlib -static -L../../libc -o nss-test nss-test.o >../../csu/i386-elf/crt1.o ../../csu/i386-elf/crti.o -lc > $ ./nss-test > files called > files called > retval = 1 > NS_SUCCESS > Bus error (core dumped) I wasn't reading this too closely, but if you're trying to hand feed in the object files, the C startup object file *MUST* come first in the list of object files, because it's gotta link at the lowest address ... Is that it? ---- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inner workings of the C compiler
On Fri, 10 Mar 2000, Oscar Bonilla wrote: > On Fri, Mar 10, 2000 at 06:51:20PM -0500, Chuck Robey wrote: > > I wasn't reading this too closely, but if you're trying to hand feed in > > the object files, the C startup object file *MUST* come first in the list > > of object files, because it's gotta link at the lowest address ... > > > > Is that it? > > Ok, I'm even more puzzled than before... This is just for a simple C program, no C++? I've been working in 2.2 and 3.4 lately, but I'll show you the trick I use, done this time for -current. Here's the trick. Write yourself a little C program, something that uses at least one include file. I don't give a damn what it does, but when you compile it, use the -v flag: gcc -v -o testme testme.c That -v flag is great for what you want, because it shows you what gcc itself is doing to get good linkages: chuckr:/usr1/chuckr:167 >gcc -v -o testme testme.c Using builtin specs. gcc version 2.95.2 19991024 (release) /usr/libexec/cpp -lang-c -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -Dunix -D__FreeBSD__=4 -D__FreeBSD_cc_version=44 -D__i386__ -D__unix__ -D__FreeBSD__=4 -D__FreeBSD_cc_version=44 -D__i386 -D__unix -Acpu(i386) -Amachine(i386) -Asystem(unix) -Asystem(FreeBSD) -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -D__ELF__ testme.c /tmp/ccD35733.i GNU CPP version 2.95.2 19991024 (release) (i386 FreeBSD/ELF) #include "..." search starts here: #include <...> search starts here: /usr/include /usr/include End of search list. The following default directories have been omitted from the search path: /usr/include/g++ End of omitted list. /usr/libexec/cc1 /tmp/ccD35733.i -quiet -dumpbase testme.c -version -o /tmp/ccj35733.s GNU C version 2.95.2 19991024 (release) (i386-unknown-freebsd) compiled by GNU C version 2.95.2 19991024 (release). /usr/libexec/elf/as -v -o /tmp/ccn35733.o /tmp/ccj35733.s GNU assembler version 2.9.1 (i386-unknown-freebsdelf), using BFD version 2.9.1 /usr/libexec/elf/ld -m elf_i386 -dynamic-linker /usr/libexec/ld-elf.so.1 -o testme /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/crtbegin.o -L/usr/libexec/elf -L/usr/libexec -L/usr/lib /tmp/ccn35733.o /usr/lib/libgcc.a -lc /usr/lib/libgcc.a /usr/lib/crtend.o /usr/lib/crtn.o Notice here the order it links, and what files it links in. First, if you're using nostdlib, then you have to call out your own libs, all of them, and you forgot to do libgcc. I've been able to move the lib calls before and after the object files, so I don't think that order matters, as long as you get both, but the objects (in order) are: crt1.o crti.o crtbegin.o ccn35733.o (your obj, that is) , then crtend.o crtn.o It calls out the ld-elf.so.1, but I don't think that's really linked in. I've been doing all my stuff statically linked, so I could be wrong on that part of it. I don't think you need to care about the -L calls, because when you use the full path, -L doesn't really matter. Always remember that -v, when your messing with tools. Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead ?(NO)
On Sat, 11 Mar 2000, Paul Richards wrote: > It's interesting that everyone is jumping up and down worrying about the > effect that the merger between BSDI and WC will have. As you say, in > *theory* FreeBSD has nothing to do with WC and is a totally independent > project. > > In practice however WC has manoeuvered their market position over the > last few years to be the "FreeBSD company" rather than a seller of > cdroms. It's worth noting that BSDI isn't merging with WC because they > need a cdrom division, they're merging with WC because to all intents > and purposes they own many of the assets of the FreeBSD project. Most of > the resources of the project are held by WC and a fair number of the key > developers are on the payroll. I do hope that BSDI doesn't minimize that part of WC; a lot of WC's other cdroms are really nice ones. Anyhow, guys, you're handling this thing with the paranoid crowd all wrong. We need to post this notice on Hackers: NOTICE: We know who you are! Anyone making strange, baseless accusations about a very unlikely BSDI conspiracy, we're going to put you on a List! A VERY SECRET list. We won't tell you who's on the List! Please post about it again, so we can get your names! The CIA will get this List! The US Post Office will get this List! Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
nm output
I'm looking through a nm listing for a static (unstripped) binary, and I keep seeing these things with the name ".Ltext0". Anyone ever see these things, or have any idea what they are? -------- Chuck Robey| Interests include C & Java programming, FreeBSD, [EMAIL PROTECTED] | electronics, communications, and signal processing. New Year's Resolution: I will not sphroxify gullible people into looking up fictitious words in the dictionary. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
