pointer for thread safe resolver stuff?
Hey, I'm not having much fun trying to find threadsafe code to do gethostbyname_r, someone pointed me at Bind9 which has what looks like some threadsafe stuff, however I can't seem to find any docco for it. (such as how to init the hostent that I pass to it and which functions are trully threadsafe) I'm going to keep reading the library source (and cursing the ISC) but I was wondering if anyone knew of any docs for the bind9 stuff or any other thread safe (non-GPL'd) resolver library. thanks, -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
I'm new to FreeBSD, but an experienced kernel guy. I'm workgin with
4.1.1 on IA32 and need help understanding the ways of your world. :-)
I'd like my project to look like a "normal" driver and use supported
interfaces, but I'll patch the core code if I need to.
This willingness is good. 8)
I have a need to walk the PCI bus, gleaning PCI IDs and other data.
(Yes, I know a dozen reasons why to NOT do that.) What I *almost*
need is the loop in pci_ioctl that walks pci_dev[]. The catch here is
that this is a private data structure (static, lots of dependencies on
private headers not in sys/..., etc) and therefore unavailable. I
considered calling the ioctl code myself from withing my driver, but
that seems too weird. I thought about shipping the data to myself by
way of user-space (daemon does an ioctl ('pciconf -l'ish) to PCI driver,
turns around and hands data to me on an ioctl) but that sounds like an
application to be punished.
It's definitely not the "right" way to do things. As Ken asked - why are
you doing things this way? Are the devices you're interested in likely
to be attached to by drivers of their own? Is your driver always going
to be in the kernel, or is it liable to be loaded as a module?
Is there a "normal" way for a conforming driver to walk the busses,
pluck out bus number, slot number, device id, subsystem id, and all that
traditional stuff, or do I just need to carve up pci.c and build my own
interface to do it?
There isn't a "normal" way for this, because in our view of the world
that's the wrong way to do it. (Whether that's absolutely right is
entirely open to debate, of course.) In most cases, you can achieve the
same thing using other techniques.
Also, I have a question on loadable character devices. Is there a way
to avoid the hard-coded major numbers in the cdevsw[] entry that's
passed? It seems like make_dev() should be able to roam cdevsw, find
an empty slot, and create the dev nodes for me. I'm envisioning a very
dynamic system with lots of modules (enough that we really don't want to
allocate them with a human involved) being popped in and out and would
like to not handle the major number management and inevitable conflicts
on my own.
This is what devfs is meant to achieve. Unfortunately at the moment the
major numbers need to be fixed because there's no dynamism in /dev. If
you don't need the /dev nodes, then of course you don't need major
numbers at all...
How is this handled for, say, third-party drivers?
Typically in the past we've just handed out major numbers to vendors
wanting to ship public drivers, or for in-house stuff just advocated using
the "local" ranges.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view. [Dr. Fritz Todt]
V I C T O R Y N O T V E N G E A N C E
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
In that case it might be that they are using some kind of private command to set the SCSI subsequently to different IDs. I'll check whether I have the device here and if so, I will try and snoop that command off the wire. Thanks for the pointer! Nick On Sun, 12 Nov 2000, James FitzGibbon wrote: * Nick Hibma ([EMAIL PROTECTED]) [001112 06:01]: I don't know. The only thing I know is that the protocol on the USB wire does not let you select the SCSI id, just the LUN. I've confirmed that under Windows this cable works with any SCSI ID, but only if you install the Microtech driver. Otherwise, it doesn't show up (i.e. identical to FBSD). Presuming that their driver is actually just a ID mapping layer, would the same thing be feasible under BSD? I'll fire off a note to their support people and see if they can at least confirm my line of thinking here. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 -- Qube Software, Ltd. Private: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.qubesoft.com/ http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
On Sun, 12 Nov 2000, Nick Hibma wrote: I don't know. The only thing I know is that the protocol on the USB wire does not let you select the SCSI id, just the LUN. Since you can select the LUN and not the ID, maybe they've mapped SCSI ID0:LUN0 to ID0:LUN0 (duh), ID1:LUN0 to ID0:LUN1, ID2:LUN0 to ID0:LUN2, and so on, which would explain why we only see a device at ID0:LUN0 if we aren't looking at the remaining LUNs (are we?). This would mean that you can't use multi-LUN devices with the USB-SCSI converter, but that is much more acceptable than only being able to use ID0 with it. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64 and PowerPC under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
STABLE ATAPI CD-ROM
Yesterday, I've CVSuped -STABLE and UPGRADE using information in /usr/src/UPDATING from 4.1.1-STABLE. make buildworld make buildkernel KERNEL=YOUR_KERNEL_HERE make installkernel KERNEL=YOUR_KERNEL_HERE reboot (in single user) [1] make installworld mergemaster reboot The problem is that my CD-ROM device suddenly disappeared. It worked before I made this upgrade. I use DELL OptiPlex GX300 with atapci0: Intel ICH ATA66 controller port 0xffa0-0xffaf at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ad0: 9765MB Maxtor 51024U2 [19841/16/63] at ata0-master UDMA66 In my kernel config file for ATA devices I have : device ata0at isa? port IO_WD1 irq 14 device ata1at isa? port IO_WD2 irq 15 device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #optionsATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices It's strange that ata1 is not recognized during boot procedure. I've tried to remove both lines from config file that described ata0 and ata1 but the result was the same. Any ideas? -- Dimitar Peikov Programmer Analyst "We Build e-Business" RILA Solutions 27 Building, Acad.G.Bonchev Str. 1113 Sofia, Bulgaria home: (+359 2) 595495 phone: (+359 2) 9797320 phone: (+359 2) 9797300 fax: (+359 2) 9733355 http://www.rila.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: STABLE ATAPI CD-ROM
It seems Dimitar V. Peikov wrote: Yesterday, I've CVSuped -STABLE and UPGRADE using information in /usr/src/UPDATING from 4.1.1-STABLE. Re-cvsup, this has been fixed... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Smart And Friendly Burner?
Hi, Anyone else have a smart and friendly cd burner? When I boot I get this: /kernel: acd0: CDROM ATAPI CD ROM DRIVE 50X MAX at ata1-master using UDMA33 /kernel: ata1-slave: timeout waiting for command=ef s=00 e=00 /kernel: ata1-slave: timeout waiting for command=ef s=00 e=00 /kernel: ata1-slave: SAF CD-RW4424A/1.09 CDROM device -NO DRIVER! I'm running 4.2 RC1 (the iso out on the ftp site). I've since recompiled the kernel (commenting out a lot of things) and I get this now: /kernel: acd1: CD-RW SAF CD-RW4424A at ata1-slave using WDMA2 So it looks fine now. I haven't added to the kernel, just removed stuff. If needed, I could send the conf file. Daryl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
* Chris Dillon ([EMAIL PROTECTED]) [001113 08:22]: On Sun, 12 Nov 2000, Nick Hibma wrote: I don't know. The only thing I know is that the protocol on the USB wire does not let you select the SCSI id, just the LUN. Since you can select the LUN and not the ID, maybe they've mapped SCSI ID0:LUN0 to ID0:LUN0 (duh), ID1:LUN0 to ID0:LUN1, ID2:LUN0 to ID0:LUN2, and so on, which would explain why we only see a device at ID0:LUN0 if we aren't looking at the remaining LUNs (are we?). This would mean that you can't use multi-LUN devices with the USB-SCSI converter, but that is much more acceptable than only being able to use ID0 with it. I've got a Nakamichi mj-4.8s (4 disc scsi jukebox) at home that I can put in an external case to test this premise. It comes up as the chosen ID and LUNS 0-3. -- j. James FitzGibbon [EMAIL PROTECTED] Targetnet.com Inc. Voice/Fax +1 416 306-0466/0452 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KLDs and PCI?
In message [EMAIL PROTECTED] "Chris Ptacek" writes: : I am working on a KLD for a PCI device. My problem is I can't find how to : call the probe and attach calls during the load for a PCI device. I have : looked in the /usr/src/sys/pci directory and haven't found any KLDs to use : as an example. What are the steps I need to take to handle a PCI device in : a KLD? Are there any examples I can look out? It just works for PCI in 4.0 and newer. : Oh yeah, I am doing this for a FreeBSD 3.x system (I know, but is needed for : this project, it will be ported to 4.x later) Ah. Well, that's different. You should be able to look at the if_* directory because it has klds in 3.x and they seem to get their probe routines called when loaded after boot. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
In message [EMAIL PROTECTED] Robert Lipe writes: : Is there a "normal" way for a conforming driver to walk the busses, : pluck out bus number, slot number, device id, subsystem id, and all that : traditional stuff, or do I just need to carve up pci.c and build my own : interface to do it? You may need to carve up pci.c, but there will likely be resistance to such a change. You rarely, if ever, need to do this from a driver. : Also, I have a question on loadable character devices. Is there a way : to avoid the hard-coded major numbers in the cdevsw[] entry that's : passed? It seems like make_dev() should be able to roam cdevsw, find : an empty slot, and create the dev nodes for me. I'm envisioning a very : dynamic system with lots of modules (enough that we really don't want to : allocate them with a human involved) being popped in and out and would : like to not handle the major number management and inevitable conflicts : on my own. No. Get a major number from us and avoid confusion. Or wait for 5.0 and devfs. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
On Mon, Nov 13, 2000 at 08:51:37 -0600, Robert Lipe wrote: Kenneth D. Merry wrote: What does your driver do? It's not a driver as much as driver infrastructure. To measure the difficulty of porting the UDI Reference Implementation (available source soon!) I decided to try porting it to an OS that I knew little about. Ahh. UDI has a concept somewhat like that expressed in the core BSD bus enumeration code where you have a bus/bridge driver that enumerates children (additional busses or cards) which may each enumerate additional children. It looks like the normal BSD interfaces to the PCI bus assumes that I am one of those children. This is understandable and has parallels in UDI-land. What I really want is to be able to walk the installed/supported busses for a chance to bind them to UDI drivers. So I don't really want to replace the existing tree-builder, I'd like to make something somewhat parallel to it. Alternately, if there's a standard interface to a system configuration database that stores this tree, I could walk that table and hand that information to my bridge driver. UnixWare (resmgr), HP/UX (cdio) , and AIX (can't recall the name of it) have such interfaces. That is probably the direction you want to go in. We've got a device infrastructure already (new-bus), which is probably what you want to use. If you probed and attached UDI devices apart from new-bus, you'll probably run into all sorts of resource conflicts. (cards with two drivers attached and stepping on each other...) Unfortunately I don't know much about new-bus, so I can't tell you how easy it would be to do what you want to do with it. (There are other folks on this list who do know, though.) I do know that we have the concept of probe priorities, so you could probably set up UDI to probe at a higher priority than the default system drivers, and therefore attach instead of the default FreeBSD driver for a given piece of harware. If you do need to get at the data, the easiest thing to do would be to un-staticize pci_devq (in pci.c), and include pci/pcivar.h in your program, to get the definition for struct pci_devinfo. I went down that path, but then got sucked into a morass of chained includes that didn't have an obvious end. It looks like pci_devq has most of the interesting information that I'm looking for. (Not suprising since I'm wanting to do with that data pretty much what pci.c is doing with it...) Yep. That's probably not the way to go for what you're doing, though. code. If this is a driver you're going to want to ship in source or module form, It is. I'd like the reference implementation to ship in source form. It currently make extensive use of modules. Cool, it'll be interesting to see the source. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
Kenneth D. Merry wrote: On Mon, Nov 13, 2000 at 08:51:37 -0600, Robert Lipe wrote: Kenneth D. Merry wrote: That is probably the direction you want to go in. We've got a device infrastructure already (new-bus), which is probably what you want to use. This is the second mention I've heard of this. I'm about to travel, but will investigate newbus upon my return. If you probed and attached UDI devices apart from new-bus, you'll probably run into all sorts of resource conflicts. (cards with two drivers attached and stepping on each other...) We have variations of this problems in other OSes. If you have two different drivers for the exact same piece of hardware, which one do you use? (One of the OSes answers "both" which works really well when you pop the second one in and it resets the hardware that's controlling your root filesystem. :-) I do know that we have the concept of probe priorities, so you could probably set up UDI to probe at a higher priority than the default system drivers, and therefore attach instead of the default FreeBSD driver for a given piece of harware. That's clever. It is. I'd like the reference implementation to ship in source form. It currently make extensive use of modules. Cool, it'll be interesting to see the source. It's a brief time (low nubmer of weeks) until the NDAs on the reference implementation go away. I have the core stuff up on FreeBSD/IA32, but I probably won't be able to get it over the finish line by myself. Many of the concepts have mapped very well so far. Thanx, RJL To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Smart And Friendly Burner?
It seems Daryl Chance wrote: Hi, Anyone else have a smart and friendly cd burner? When I boot I get this: /kernel: acd0: CDROM ATAPI CD ROM DRIVE 50X MAX at ata1-master using UDMA33 /kernel: ata1-slave: timeout waiting for command=ef s=00 e=00 /kernel: ata1-slave: timeout waiting for command=ef s=00 e=00 /kernel: ata1-slave: SAF CD-RW4424A/1.09 CDROM device -NO DRIVER! I'm running 4.2 RC1 (the iso out on the ftp site). I've since recompiled the kernel (commenting out a lot of things) and I get this now: /kernel: acd1: CD-RW SAF CD-RW4424A at ata1-slave using WDMA2 So it looks fine now. I haven't added to the kernel, just removed stuff. If needed, I could send the conf file. You dont mention what version on FreeBSD we are talking about here, in any case you should upgrade to the latest version on the branch you are on... What exactly have you removed ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Smart And Friendly Burner?
I burned the copy from the 4.2RC1 iso found on the ftp site. doing a list on / shows the kernel was compiled on Nov 7th. When I recompiled the kernel (not adding, just commenting stuff out) It showed the message that looked fine. (/kernel: acd1: CD-RW SAF CD-RW4424A at ata1-slave using WDMA2) The first message I got with the default kernel. I went ahead and attached my config file. HTH, --- | Daryl Chance | We start seeing these new accounts being created, | | -- | but that could be an anomaly of the system. After | | Valuedata, LLC | a day or two, we realized it was someone hacking | | Memphis, TN| into the system. - Microsoft on thier hacker | --- - Original Message - From: "Soren Schmidt" [EMAIL PROTECTED] To: "Daryl Chance" [EMAIL PROTECTED] Cc: "FreeBSD Hackers" [EMAIL PROTECTED] Sent: Monday, November 13, 2000 1:21 PM Subject: Re: Smart And Friendly Burner? It seems Daryl Chance wrote: Hi, Anyone else have a smart and friendly cd burner? When I boot I get this: /kernel: acd0: CDROM ATAPI CD ROM DRIVE 50X MAX at ata1-master using UDMA33 /kernel: ata1-slave: timeout waiting for command=ef s=00 e=00 /kernel: ata1-slave: timeout waiting for command=ef s=00 e=00 /kernel: ata1-slave: SAF CD-RW4424A/1.09 CDROM device -NO DRIVER! I'm running 4.2 RC1 (the iso out on the ftp site). I've since recompiled the kernel (commenting out a lot of things) and I get this now: /kernel: acd1: CD-RW SAF CD-RW4424A at ata1-slave using WDMA2 So it looks fine now. I haven't added to the kernel, just removed stuff. If needed, I could send the conf file. You dont mention what version on FreeBSD we are talking about here, in any case you should upgrade to the latest version on the branch you are on... What exactly have you removed ? -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message chancedj
RE: simple lock and the lost wakeup problem
On 12-Nov-00 Zhiui Zhang wrote: I am new to SMP subject and have some questions to ask: Is the simplelock() really needed since FreeBSD is using the big giant lock and the kernel is non preemptive? Or has FreeBSD changed the big giant lock and made kernel thread preemptive? Uresha Vahalia talks about Lost Wakeup Problem (page 196), the test of the resource and sleep() has to be done atomically. Which correct mechanism should I use on FreeBSD to achieve this (avoid the lost-wakeup problem)? simplelocks are used in interrupt handlers and a few other places that do not run while holding the big giant lock. In -current all of this has changed, however, as we now have mutexes. Most of the kernel is still under the Giant mutex at this point in time, but in the future Giant will be replaced by many other locks that protect data structures within the kernel. To avoid the lost wakeup problem I think you are referring to (I don't have Unix Internals here with me @ home) in -current, we have a replacment for tsleep() called msleep(). msleep() takes an additional parameter which is a mutex to release when going to sleep. From the kernel's perspective, the mutex is released and the process is put to sleep as an atomic operation. Hope this helps. Any help is appreciated. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-smp" in the body of the message -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB-to-SCSI converter
On Mon, Nov 13, 2000 at 10:38:44AM -0500, James FitzGibbon wrote: * Chris Dillon ([EMAIL PROTECTED]) [001113 08:22]: On Sun, 12 Nov 2000, Nick Hibma wrote: I don't know. The only thing I know is that the protocol on the USB wire does not let you select the SCSI id, just the LUN. Since you can select the LUN and not the ID, maybe they've mapped SCSI ID0:LUN0 to ID0:LUN0 (duh), ID1:LUN0 to ID0:LUN1, ID2:LUN0 to ID0:LUN2, and so on, which would explain why we only see a device at ID0:LUN0 if we aren't looking at the remaining LUNs (are we?). This would mean that you can't use multi-LUN devices with the USB-SCSI converter, but that is much more acceptable than only being able to use ID0 with it. I've got a Nakamichi mj-4.8s (4 disc scsi jukebox) at home that I can put in an external case to test this premise. It comes up as the chosen ID and LUNS 0-3. And the nice thing is that it is known-good on FreeBSD on plain SCSI. I have one here on 4.2-beta which works like a charm. -- Wilko Bulte Arnhem, the Netherlands [EMAIL PROTECTED] http://www.freebsd.org http://www.nlfug.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Log analysis program running under apache reboots server!
Greetings all.. I have been trying to test an apache log analizing program called Nettracker (.sane.com) the program seems nice except for the fact that it keeps rebooting/crashing the server. This would just be labeled crappy software except for the fact that I am running the software as user apache and have setup process limits in login.conf and it is still able to reboot the server. This seems like a real problem and security issue as I have setup limits in /etc/login.conf (see below) and the program is being run via CGI as user apache, yet it is still capable of rebooting the system. Seems like a nice hack to me. If anyone could check over my login.conf settings below and make sure they are correct/ truly usefull, I would really appreciate it! Also any information on how this program could so easily reboot the server would be nice too. Thanks!! Nicole System is 4.1-STABLE and has 256 Megs of memory and 4X that of swap. apacheuser:\ :manpath=/usr/share/man /usr/X11R6/man /usr/local/man:\ :cputime=4h:\ :datasize=64M:\ :stacksize=4M:\ :filesize=infinity:\ :memoryuse=64M:\ :priority=0:\ :datasize-cur=32M:\ :stacksize-cur=32M:\ :coredumpsize-cur=0:\ :maxmemorysize-cur=64M:\ :memorylocked=32M:\ :maxproc=128:\ :openfiles=256:\ :tc=standard: ## standard - standard user defaults ## standard:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin /bin /usr/bin /usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/var/run/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=90d:\ :umask=002:\ :ignoretime@:\ :tc=default: default:\ :cputime=infinity:\ :datasize-cur=22M:\ :stacksize-cur=8M:\ :memorylocked-cur=10M:\ :memoryuse-cur=30M:\ :filesize=infinity:\ :coredumpsize=infinity:\ :maxproc-cur=64:\ :openfiles-cur=64:\ :priority=0:\ :requirehome@:\ :umask=022:\ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Log analysis program running under apache reboots server!
Nicole, Is it a panic, or does it just silently reboot? If it's a panic, what is the panic message, or any other message on the console when the system crashes? Also, can you get a crash dump? (see the dumpon(8) man page) -brian On Mon, Nov 13, 2000 at 10:58:39AM -0800, Nicole Harrington wrote: Greetings all.. I have been trying to test an apache log analizing program called Nettracker (.sane.com) the program seems nice except for the fact that it keeps rebooting/crashing the server. This would just be labeled crappy software except for the fact that I am running the software as user apache and have setup process limits in login.conf and it is still able to reboot the server. This seems like a real problem and security issue as I have setup limits in /etc/login.conf (see below) and the program is being run via CGI as user apache, yet it is still capable of rebooting the system. Seems like a nice hack to me. If anyone could check over my login.conf settings below and make sure they are correct/ truly usefull, I would really appreciate it! Also any information on how this program could so easily reboot the server would be nice too. Thanks!! Nicole System is 4.1-STABLE and has 256 Megs of memory and 4X that of swap. apacheuser:\ :manpath=/usr/share/man /usr/X11R6/man /usr/local/man:\ :cputime=4h:\ :datasize=64M:\ :stacksize=4M:\ :filesize=infinity:\ :memoryuse=64M:\ :priority=0:\ :datasize-cur=32M:\ :stacksize-cur=32M:\ :coredumpsize-cur=0:\ :maxmemorysize-cur=64M:\ :memorylocked=32M:\ :maxproc=128:\ :openfiles=256:\ :tc=standard: ## standard - standard user defaults ## standard:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin /bin /usr/bin /usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/var/run/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=90d:\ :umask=002:\ :ignoretime@:\ :tc=default: default:\ :cputime=infinity:\ :datasize-cur=22M:\ :stacksize-cur=8M:\ :memorylocked-cur=10M:\ :memoryuse-cur=30M:\ :filesize=infinity:\ :coredumpsize=infinity:\ :maxproc-cur=64:\ :openfiles-cur=64:\ :priority=0:\ :requirehome@:\ :umask=022:\ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/pciconf vendors.h pciconf.8 pciconf.c
On Mon 2000-11-13 (12:24), Roger Hardiman wrote: Mike Smith wrote: The downside of this is that it bloats pciconf from about 5k to about 130k. If someone feels passionately about this, they're welcome to add a compile-time option to leave the strings out. We will have to add this for PicoBSD where we want the kernel nice and small. Joe - you listening? pciconf isn't on any picobsd images I've seem. However, we can save a lot of space by reorganizing pci/pcisupport.c in such a way to make it easy to drop text identifiers for the pci devices. I seem to remember posting one way to do it to -arch a while back. It was a sizable win on the images I was playing with. Anyone interested can look at the (now heavily outdated) patch and recreate it. phk suggested there be one massive table, but I used a table per device type. I'm uncertain as to what others think on that. Cheers, Neil -- Neil Blakey-Milner [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Log analysis program running under apache reboots server!
On 13-Nov-00 Brian O'Shea wrote: Nicole, Is it a panic, or does it just silently reboot? If it's a panic, what is the panic message, or any other message on the console when the system crashes? Also, can you get a crash dump? (see the dumpon(8) man page) -brian Silent reboot :( Nicole On Mon, Nov 13, 2000 at 10:58:39AM -0800, Nicole Harrington wrote: Greetings all.. I have been trying to test an apache log analizing program called Nettracker (.sane.com) the program seems nice except for the fact that it keeps rebooting/crashing the server. This would just be labeled crappy software except for the fact that I am running the software as user apache and have setup process limits in login.conf and it is still able to reboot the server. This seems like a real problem and security issue as I have setup limits in /etc/login.conf (see below) and the program is being run via CGI as user apache, yet it is still capable of rebooting the system. Seems like a nice hack to me. If anyone could check over my login.conf settings below and make sure they are correct/ truly usefull, I would really appreciate it! Also any information on how this program could so easily reboot the server would be nice too. Thanks!! Nicole System is 4.1-STABLE and has 256 Megs of memory and 4X that of swap. apacheuser:\ :manpath=/usr/share/man /usr/X11R6/man /usr/local/man:\ :cputime=4h:\ :datasize=64M:\ :stacksize=4M:\ :filesize=infinity:\ :memoryuse=64M:\ :priority=0:\ :datasize-cur=32M:\ :stacksize-cur=32M:\ :coredumpsize-cur=0:\ :maxmemorysize-cur=64M:\ :memorylocked=32M:\ :maxproc=128:\ :openfiles=256:\ :tc=standard: ## standard - standard user defaults ## standard:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin /bin /usr/bin /usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/var/run/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=90d:\ :umask=002:\ :ignoretime@:\ :tc=default: default:\ :cputime=infinity:\ :datasize-cur=22M:\ :stacksize-cur=8M:\ :memorylocked-cur=10M:\ :memoryuse-cur=30M:\ :filesize=infinity:\ :coredumpsize=infinity:\ :maxproc-cur=64:\ :openfiles-cur=64:\ :priority=0:\ :requirehome@:\ :umask=022:\ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ [EMAIL PROTECTED] // \\http://www.deviantimages.com/ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Strong as any man - made for a Woman -- -- "I drank WHAT ?!" - Socrates -- Hmm You seem better - "been giving myself shock treatments" Up the Voltage! - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Log analysis program running under apache reboots server!
On 13-Nov-00 Nicole H wrote: On 13-Nov-00 Brian O'Shea wrote: Nicole, Is it a panic, or does it just silently reboot? If it's a panic, what is the panic message, or any other message on the console when the system crashes? Also, can you get a crash dump? (see the dumpon(8) man page) -brian Silent reboot :( I hate to respond to my own message.. But the server is remote.. But there is nothing in the logs afterwards.. and nothing appears on the screen when it occurs. Nicole Nicole On Mon, Nov 13, 2000 at 10:58:39AM -0800, Nicole Harrington wrote: Greetings all.. I have been trying to test an apache log analizing program called Nettracker (.sane.com) the program seems nice except for the fact that it keeps rebooting/crashing the server. This would just be labeled crappy software except for the fact that I am running the software as user apache and have setup process limits in login.conf and it is still able to reboot the server. This seems like a real problem and security issue as I have setup limits in /etc/login.conf (see below) and the program is being run via CGI as user apache, yet it is still capable of rebooting the system. Seems like a nice hack to me. If anyone could check over my login.conf settings below and make sure they are correct/ truly usefull, I would really appreciate it! Also any information on how this program could so easily reboot the server would be nice too. Thanks!! Nicole System is 4.1-STABLE and has 256 Megs of memory and 4X that of swap. apacheuser:\ :manpath=/usr/share/man /usr/X11R6/man /usr/local/man:\ :cputime=4h:\ :datasize=64M:\ :stacksize=4M:\ :filesize=infinity:\ :memoryuse=64M:\ :priority=0:\ :datasize-cur=32M:\ :stacksize-cur=32M:\ :coredumpsize-cur=0:\ :maxmemorysize-cur=64M:\ :memorylocked=32M:\ :maxproc=128:\ :openfiles=256:\ :tc=standard: ## standard - standard user defaults ## standard:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin /bin /usr/bin /usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/var/run/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=90d:\ :umask=002:\ :ignoretime@:\ :tc=default: default:\ :cputime=infinity:\ :datasize-cur=22M:\ :stacksize-cur=8M:\ :memorylocked-cur=10M:\ :memoryuse-cur=30M:\ :filesize=infinity:\ :coredumpsize=infinity:\ :maxproc-cur=64:\ :openfiles-cur=64:\ :priority=0:\ :requirehome@:\ :umask=022:\ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ [EMAIL PROTECTED] // \\http://www.deviantimages.com/ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Strong as any man - made for a Woman -- -- "I drank WHAT ?!" - Socrates -- Hmm You seem better - "been giving myself shock treatments" Up the Voltage! - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message [EMAIL PROTECTED] |\ __ /| (`\ http://www.unixgirl.com/ [EMAIL PROTECTED] | o_o |__ ) ) http://www.dangermouse.org/ [EMAIL PROTECTED] // \\http://www.deviantimages.com/ ---(((---(((- -- Powered by Coka-Cola and FreeBSD -- -- Strong as any man - made for a Woman -- -- "I drank WHAT ?!" - Socrates -- Hmm You seem better - "been giving myself shock treatments" Up the Voltage! - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Log analysis program running under apache reboots server!
Likely, you're getting a panic() and since you likely don't have debugging options, the machine eventually reboots itself. Notice that this is all "likely" and that since we don't have a crash dump, stack trace, or similar debugging information, that there's not much that can be done except guessing. I would suggest that you try to reproduce the problem on a local machine and get some debugging info. On Mon, 13 Nov 2000, Nicole wrote: Silent reboot :( I hate to respond to my own message.. But the server is remote.. But there is nothing in the logs afterwards.. and nothing appears on the screen when it occurs. Nicole [...] apacheuser:\ :manpath=/usr/share/man /usr/X11R6/man /usr/local/man:\ :cputime=4h:\ :datasize=64M:\ :stacksize=4M:\ :filesize=infinity:\ :memoryuse=64M:\ :priority=0:\ :datasize-cur=32M:\ :stacksize-cur=32M:\ :coredumpsize-cur=0:\ :maxmemorysize-cur=64M:\ :memorylocked=32M:\ :maxproc=128:\ :openfiles=256:\ :tc=standard: ## standard - standard user defaults ## standard:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin /bin /usr/bin /usr/local/bin:\ :manpath=/usr/share/man /usr/local/man:\ :nologin=/var/run/nologin:\ :cputime=1h30m:\ :datasize=8M:\ :stacksize=2M:\ :memorylocked=4M:\ :memoryuse=8M:\ :filesize=8M:\ :coredumpsize=8M:\ :openfiles=24:\ :maxproc=32:\ :priority=0:\ :requirehome:\ :passwordtime=90d:\ :umask=002:\ :ignoretime@:\ :tc=default: default:\ :cputime=infinity:\ :datasize-cur=22M:\ :stacksize-cur=8M:\ :memorylocked-cur=10M:\ :memoryuse-cur=30M:\ :filesize=infinity:\ :coredumpsize=infinity:\ :maxproc-cur=64:\ :openfiles-cur=64:\ :priority=0:\ :requirehome@:\ :umask=022:\ For starters, I don't see "sbsize" in there, although it doesn't sound like something that should be causing a panic() anymore anyway. Please provide more debugging infos. Thanks, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Log analysis program running under apache reboots server!
On Mon, Nov 13, 2000 at 11:56:37AM -0700, Nicole H wrote: On 13-Nov-00 Brian O'Shea wrote: Nicole, Is it a panic, or does it just silently reboot? If it's a panic, what is the panic message, or any other message on the console when the system crashes? Also, can you get a crash dump? (see the dumpon(8) man page) -brian Silent reboot :( Be sure the machine is setup to capture a crashdump on panic. I had a machine that was doing this, and wehn I got it to do proper crashdumps, I got a good lead on the problem. in my case, I set aside a raw partition, and setup this in rc.conf: dumpdev="/dev/rda2s1h" # Device name to crashdump to (if enabled). Then I symlinked /var/crash to someplace else, because my /var wasn't too big. Good Luck. -- Robert Sexton - [EMAIL PROTECTED], Cincinnati OH, USA The individual choice of garnishment of a burger can be an important point to the consumer in this day when individualism is an increasingly important thing to people. -- Donald N. Smith, president of Burger King To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
patches for 4.x devrandom so that bind works
I was playing with bind9 and got the typical:
On FreeBSD systems, the server logs error messages like "fcntl(8,
F_SETFL, 4): Inappropriate ioctl for device". This is due to
a bug in the FreeSBD /dev/random device. The bug has been
reported to the FreeBSD maintainers. Versions of OpenBSD prior
to 2.8 have a similar problem.
I took a look at what OpenBSD did and it looks like they just
no-op'd out the ioctl:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c?r1=1.40r2=1.41
I have a patch that seems to shut bind up, but I'm not 100% sure
this is the right fix, as it looks like it just fakes the nonblocking
access to the random devices.
Here's my patch (I can probably generate this for alpha):
Index: mem.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mem.c,v
retrieving revision 1.79.2.4
diff -u -u -r1.79.2.4 mem.c
--- mem.c 2000/08/04 22:31:07 1.79.2.4
+++ mem.c 2000/11/13 23:53:43
@@ -57,6 +57,7 @@
#include sys/proc.h
#include sys/random.h
#include sys/signalvar.h
+#include sys/filio.h
#include sys/uio.h
#include machine/frame.h
@@ -465,8 +466,20 @@
* selecting and inspecting which interrupts are used in the muck
* gathering business.
*/
- if (cmd != MEM_SETIRQ cmd != MEM_CLEARIRQ cmd != MEM_RETURNIRQ)
+ switch (cmd) {
+ case FIOASYNC:
+ /* rnd has no async flag in softc so this is really a no-op. */
+ /* FALLTHROUGH */
+ case FIONBIO:
+ /* Handled in the upper FS layer. */
+ return (0);
+ case MEM_SETIRQ:
+ case MEM_CLEARIRQ:
+ case MEM_RETURNIRQ:
+ break;
+ default:
return (ENOTTY);
+ }
/*
* Even inspecting the state is privileged, since it gives a hint
Did I miss part of the OpenBSD delta? This looks too easy. :(
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
Robert Lipe wrote: Kenneth D. Merry wrote: I do know that we have the concept of probe priorities, so you could probably set up UDI to probe at a higher priority than the default system drivers, and therefore attach instead of the default FreeBSD driver for a given piece of harware. That's clever. As far as I understand, that's not too easy: most drivers' probes return the highest priority, so you won't be able to override them. But doing the other way is easy: just return a lower priority and the UDI driver will be used only if there is no native driver. Actually, if there are multiple drivers returning the same priority then one will be selected at random (the one appearing earlier in the table) and there still will be no conflict. May be my article http://www.daemonnews.org/28/isa.html would be of some help, it considers the ISA bus but by the way touches the general issues of the new bus architecture too. -SB (also [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pointer for thread safe resolver stuff?
Alfred Perlstein [EMAIL PROTECTED] wrote: I'm going to keep reading the library source (and cursing the ISC) but I was wondering if anyone knew of any docs for the bind9 stuff or any other thread safe (non-GPL'd) resolver library. AFAIK the bind-9 resolver is a full resolver not a stub resolver, which probably isn't what you want. I haven't checked this hearsay for myself though. Tony. -- en oeccget g mtcaaf.a.n.finch v spdlkishrhtewe y[EMAIL PROTECTED] eatp o v eiti i d.[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
zero copy TCP
I heard that zero copy TCP is already in FreeBSD, isn't it? I could not find any information in searching the entire website. Before I am going to spend some silly time working on it, I would like to know what is the status for "ZERO COPY TCP" in FreeBSD right now. If it already exists, how can I enable it (for 1500 MTU, not Jumbo Frame)? or someone is still working on it. -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: zero copy TCP
* Jin Guojun [EMAIL PROTECTED] [001113 17:49] wrote: I heard that zero copy TCP is already in FreeBSD, isn't it? I could not find any information in searching the entire website. Before I am going to spend some silly time working on it, I would like to know what is the status for "ZERO COPY TCP" in FreeBSD right now. If it already exists, how can I enable it (for 1500 MTU, not Jumbo Frame)? or someone is still working on it. It's not integrated into the source tree yet. What sort of zero copy do you hope to accomplish? Sending files? Sending preloaded data? -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Log analysis program running under apache reboots server!
On Mon, Nov 13, 2000 at 11:56:37AM -0700, Nicole H wrote: On 13-Nov-00 Brian O'Shea wrote: Nicole, Is it a panic, or does it just silently reboot? If it's a panic, what is the panic message, or any other message on the console when the system crashes? Also, can you get a crash dump? (see the dumpon(8) man page) -brian Silent reboot :( Are you logged in on a network terminal via ssh or telnet or the like, or on a serial console via a terminal server? The panic message will only appear on the console, so unless it's the latter, it will be hard to determine the cause of the problem. There are good instructions on how to get debugging information for kernel crashes here: http://www.freebsd.org/handbook/kerneldebug.html -brian -- Brian O'Shea [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: zero copy TCP
Alfred [EMAIL PROTECTED] wrote: I heard that zero copy TCP is already in FreeBSD, isn't it? I could not find any information in searching the entire website. Before I am going to spend some silly time working on it, I would like to know what is the status for "ZERO COPY TCP" in FreeBSD right now. If it already exists, how can I enable it (for 1500 MTU, not Jumbo Frame)? or someone is still working on it. It's not integrated into the source tree yet. What sort of zero copy do you hope to accomplish? Sending files? Sending preloaded data? Both, but I may do either way, depending on which way is easier. If we can directly DMA from a disk drive to a NIC, that will be great. If the current implementation requires preloaded buffer, that works. So, where can I look for the patch? Thanks, -Jin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: zero copy TCP
On Mon, 13 Nov 2000, Jin Guojun wrote: Both, but I may do either way, depending on which way is easier. If we can directly DMA from a disk drive to a NIC, that will be great. If the current implementation requires preloaded buffer, that works. So, where can I look for the patch? Thanks, -Jin Please see sendfile(2). Regards, Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for 4.x devrandom so that bind works
Hi
I have something similar to this, and it goes slightly further.
Yes, it is this simple :-).
M
I was playing with bind9 and got the typical:
On FreeBSD systems, the server logs error messages like "fcntl(8,
F_SETFL, 4): Inappropriate ioctl for device". This is due to
a bug in the FreeSBD /dev/random device. The bug has been
reported to the FreeBSD maintainers. Versions of OpenBSD prior
to 2.8 have a similar problem.
I took a look at what OpenBSD did and it looks like they just
no-op'd out the ioctl:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c?r1=1.40r2=1.41
I have a patch that seems to shut bind up, but I'm not 100% sure
this is the right fix, as it looks like it just fakes the nonblocking
access to the random devices.
Here's my patch (I can probably generate this for alpha):
Index: mem.c
===
RCS file: /home/ncvs/src/sys/i386/i386/mem.c,v
retrieving revision 1.79.2.4
diff -u -u -r1.79.2.4 mem.c
--- mem.c 2000/08/04 22:31:07 1.79.2.4
+++ mem.c 2000/11/13 23:53:43
@@ -57,6 +57,7 @@
#include sys/proc.h
#include sys/random.h
#include sys/signalvar.h
+#include sys/filio.h
#include sys/uio.h
#include machine/frame.h
@@ -465,8 +466,20 @@
* selecting and inspecting which interrupts are used in the muck
* gathering business.
*/
- if (cmd != MEM_SETIRQ cmd != MEM_CLEARIRQ cmd != MEM_RETURNIRQ)
+ switch (cmd) {
+ case FIOASYNC:
+ /* rnd has no async flag in softc so this is really a no-op. */
+ /* FALLTHROUGH */
+ case FIONBIO:
+ /* Handled in the upper FS layer. */
+ return (0);
+ case MEM_SETIRQ:
+ case MEM_CLEARIRQ:
+ case MEM_RETURNIRQ:
+ break;
+ default:
return (ENOTTY);
+ }
/*
* Even inspecting the state is privileged, since it gives a hint
Did I miss part of the OpenBSD delta? This looks too easy. :(
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
What does your driver do? It's not a driver as much as driver infrastructure. To measure the difficulty of porting the UDI Reference Implementation (available source soon!) I decided to try porting it to an OS that I knew little about. Aha! I've been waiting for this since February or so, which was the last time anyone mentioned that the UDI reference implementation was going to go public. 8) UDI has a concept somewhat like that expressed in the core BSD bus enumeration code where you have a bus/bridge driver that enumerates children (additional busses or cards) which may each enumerate additional children. It looks like the normal BSD interfaces to the PCI bus assumes that I am one of those children. This is understandable and has parallels in UDI-land. Unfortunately for UDI implementation, the only real way to do this "right" is going to be by merging the two infrastructures, ie. making it possible for UDI drivers to attach to newbus busses (and vice-versa, although that is probably asking a bit much). What I really want is to be able to walk the installed/supported busses for a chance to bind them to UDI drivers. So I don't really want to replace the existing tree-builder, I'd like to make something somewhat parallel to it. Don't. Shim the UDI drivers so that they look like "normal" newbus devices. Trying to have two sets of infrastructure "owning" the same bus/ resource domain is just going to be ugly. Alternatively, if you really want to use the UDI bus infrastructure, you'll have to merge the two fairly intimately. A third approach would be to discard the newbus code and work out how to shim existing FreeBSD drivers to live under the UDI infrastructure. Given the way that newbus works, this might not be all that easy (eg. there are cases where drivers make valid assumptions about the tree above them which would be invalidated by this). Alternately, if there's a standard interface to a system configuration database that stores this tree, I could walk that table and hand that information to my bridge driver. UnixWare (resmgr), HP/UX (cdio) , and AIX (can't recall the name of it) have such interfaces. One thing you could do, if you only care (for now) about unattached PCI devices, is to look at the way that PCI nomatch is handled, and pass these devices off to the UDI probe/attach handler. Resources for these devices can be managed using the normal bus_*_resource interface. If you do need to get at the data, the easiest thing to do would be to code. If this is a driver you're going to want to ship in source or module form, It is. I'd like the reference implementation to ship in source form. It currently make extensive use of modules. That's not an unreasonable thing to do. Note that every time you load a device module the system performs a complete bus rescan, so the nomatch handler is called for every device that hasn't already been claimed. If you want to discuss this in more detail, please do. Note also that depending on your NDA circumstances I may already be in a situation where it would be easy for you to discuss some of this material offline. I'm pretty familiar with the way that newbus and the BSD PCI code works, just not with the innards of the UDI reference implementation. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pci bus enumeration cdevsw indexing
to avoid the hard-coded major numbers in the cdevsw[] entry that's passed? It seems like make_dev() should be able to roam cdevsw, find This is what devfs is meant to achieve. Unfortunately at the moment the major numbers need to be fixed because there's no dynamism in /dev. If If you have devfs (and it means the same to you that it does to other OSes) that would solve the problem nicely. So is devfs something in 4.1.1 or is it future work? If it's here now, can you point me to an example? If it's future work, is that where I should be focusing? It's a work-in-progress for 5.0 (on the -current branch), and yes, you should most definitely be focussing there. For a UDI driver, that would be a problem. A UDI driver-writer has no clue where his target device will be running and, indeed, could be running on an OS without a /dev. So we could carve out a pool of b and c major numbers for UDI to then dynamically manage on behalf of the drivers, but that seems tedious. The environment has enough bread crumbs to know of a given driver is an HBA, a NIC, or something else and can set things up appropriately behind the scenes. Realistically, the only things that still care about device major/minor numbers are tty devices, control interfaces and non-SCSI non-ATA block devices. Having said that, DEVFS is really the only sane answer here, and it would probably be a prerequisite for anything like UDI. Regards, Mike -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: patches for 4.x devrandom so that bind works
* Mark Murray [EMAIL PROTECTED] [001113 22:17] wrote: I was playing with bind9 and got the typical: On FreeBSD systems, the server logs error messages like "fcntl(8, F_SETFL, 4): Inappropriate ioctl for device". This is due to a bug in the FreeSBD /dev/random device. The bug has been reported to the FreeBSD maintainers. Versions of OpenBSD prior to 2.8 have a similar problem. I took a look at what OpenBSD did and it looks like they just no-op'd out the ioctl: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/dev/rnd.c?r1=1.40r2=1.41 I have a patch that seems to shut bind up, but I'm not 100% sure this is the right fix, as it looks like it just fakes the nonblocking access to the random devices. Here's my patch (I can probably generate this for alpha): Index: mem.c [snip] Did I miss part of the OpenBSD delta? This looks too easy. :( Hi I have something similar to this, and it goes slightly further. Yes, it is this simple :-). Can you get it ready for 4.2? I'd like to see us be able to run bind9 in the next release. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE w/ nat auto fragmentation hack?
On Mon, 13 Nov 2000, Renaud Waldura wrote: -I wrote an article about this setup. Should be published soon enough. -http://renaud.waldura.com/doc/freebsd-pppoe/ - -I'd like to get your feedback on the section making use of tcpmssd: it -doesn't seem to work when the link is brought up automatically by ppp. - ---Renaud - Thanks Renaud, great article and very helpful. I've not got a chance to test out the PPPoE with tcpmssd yet as the machine is not local to me. (I could ssh to it but have no access to the machines behind the nat to generate some testing packets) The only thing is that tcpmssd from FreeBSD port does not have -l option. The -l option, however, is being used in your tcpmssd.rc script. My port tree is quiet new so I guess there is some difference between the tcpmssd you offered on your site and the freebsd port. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
