Re: loads of SetAttrs in cvsup of cvs repo
As Ben Smithurst wrote ... Amancio Hasty wrote: Curious why are you cvsupping every couple of minutes ? He isn't. He's saying normally when he cvsups, it only takes a couple of minutes, not that he does it every couple of minutes. At least that's the way I read it. Right, that is what I meant. Sorry, should've been more precise in my original post. Would not make a lot of sense to run cvsup every few minutes ;-) -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: loads of SetAttrs in cvsup of cvs repo
As Mark Huizer wrote ... Sun Jul 4 22:13:55 CEST 1999 yedi# cvsup version has not been changed. I did change the cvsup server some time ago, but I'm now back at cvsup.nl.FreeBSD.org hey! that's my queue! when did it start to happen? If it was last week, then there might have been some cause in the upgrading of the machine to 3.2, or it might involve softupdates. Don't worry, I checked my logs and I also saw it on June 4. But unfortunately I can't tell from the log from which server it was cvsupping. So whatever it is, it is not something that started last week. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/i386/i386 identcpu.c
ÐÎ , 05 ÉÀÌ 1999, ÷Ù ÎÁÐÉÓÁÌÉ: On Sun, 4 Jul 1999, Brian Feldman wrote: CPU: AMD-K6(tm) 3D processor (350.81-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x58c Stepping=12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x808029bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SYSCALL,PGE,MMX,3DNow! I thought the K6-* only did 3DNow, and not MMX? no, K6-* supports MMX instruction set as well as 3DNow. -- sincerely, ilya naumov (at work) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
"Brian F. Feldman" [EMAIL PROTECTED] writes: On 4 Jul 1999, Dag-Erling Smorgrav wrote: Depends on your motherboard. Try to just disable UDMA66 first. If that doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs Aladdin), disable UDMA completely in the BIOS setup utility. What do you mean, "known bad" ALi? I should have said "known bad configuration". I know Søren's ATA driver supports UDMA on the Aladdin, but I don't have the luxury of expendable file systems, so I don't use it. I also think it's the wrong direction to go off in; if we're going to totally rewrite our IDE driver, we should do it within the CAM framework. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Dag-Erling Smorgrav wrote: "Brian F. Feldman" [EMAIL PROTECTED] writes: On 4 Jul 1999, Dag-Erling Smorgrav wrote: Depends on your motherboard. Try to just disable UDMA66 first. If that doesn't help, or if you have a "known bad" chipset (e.g. AcerLabs Aladdin), disable UDMA completely in the BIOS setup utility. What do you mean, "known bad" ALi? I should have said "known bad configuration". I know Søren's ATA driver supports UDMA on the Aladdin, but I don't have the luxury of expendable file systems, so I don't use it. I also think it's the wrong direction to go off in; if we're going to totally rewrite our IDE driver, we should do it within the CAM framework. Do I hear a volounteer here ?? What the new ATA/ATAPI driver is all about is mostly a rewrite of all the low level code, and that is still needed if you want to go the CAM way. The higher levels of the new ATA driver is simply a port of my allready done ATAPI drivers. There is nothing in the way of screwing a CAM interface ontop of that lowlevel code instead of/in parallel to the current highlvel code Oh and besides that I still have to loose a filesystem to the ATA driver :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl stops make world
In message [EMAIL PROTECTED] gene writes: : This sounds old, I know zip about Perl, I think the latest is like : 5.005_04, but make in the /usr/ports/lang/perl5 directory gives me: You might want to try removing the perl port you have installed on your system, and then trying the make world again. I'd bet a couple of beers that you need to remove the NOPERL line from your /etc/make.conf file, since that is usually what causes this. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
I should have said "known bad configuration". I know Søren's ATA driver supports UDMA on the Aladdin, but I don't have the luxury of expendable file systems, so I don't use it. I also think it's the wrong direction to go off in; if we're going to totally rewrite our IDE driver, we should do it within the CAM framework. Do I hear a volounteer here ?? What the new ATA/ATAPI driver is all about is mostly a rewrite of all the low level code, and that is still needed if you want to go the CAM way. The higher levels of the new ATA driver is simply a port of my allready done ATAPI drivers. There is nothing in the way of screwing a CAM interface ontop of that lowlevel code instead of/in parallel to the current highlvel code Yes yes yes! CAM on top of ATAPI. If we keep the command creation/conversion layer in CAM and make CCB come out at the lower end, we could instantly screw it on top of the USB Mass Storage driver (that supports SCSI through CAM at the moment). On a related edge: Would it make sense to create a UFI command layer (USB floppies use it, don't know what else) on top of CAM? Or am fundamentally wrong in assuming that one can stack any command layer on top of CAM and abuse it as a layer that provides common services, command queueing, error handling? It would like this: SCSI UFI_da ATAPI \| / CAM layer | USB Mass Storage Driver / | \ Bulk CB CBI Cheers, Nick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
Soren Schmidt wrote: It seems Nick Hibma wrote: I should have said "known bad configuration". I know Søren's ATA driver supports UDMA on the Aladdin, but I don't have the luxury of expendable file systems, so I don't use it. I also think it's the wrong direction to go off in; if we're going to totally rewrite our IDE driver, we should do it within the CAM framework. Do I hear a volounteer here ?? What the new ATA/ATAPI driver is all about is mostly a rewrite of all the low level code, and that is still needed if you want to go the CAM w ay. The higher levels of the new ATA driver is simply a port of my allready done ATAPI drivers. There is nothing in the way of screwing a CAM interface ontop of that lowlevel code instead of/in parallel to the current highlvel code Yes yes yes! CAM on top of ATAPI. If we keep the command creation/conversion layer in CAM and make CCB come out at the lower end, we could instantly screw it on top of the USB Mass Storage driver (that supports SCSI through CAM at the moment). Well, CAM ATAPI is "fairly" easy, the only problem being all the little details that are different enough to make it non-trivial to maintain. I once sat down and tried to get all the details on how the CCB's where different, and decided that I wouldn't want to engage in that. Another story is ATA disks, there you either have to teach CAM about a new lowlevel protocol, or write a SCSIATA translator, which I also decided I didn't want to do... Well, that's assuming you use scsi ccb's... you could use atapi ccb's. We have cam/* which is the generic transport handler. cam/scsi/* which is the scsi peripheral drivers that use scsi ccbs, and then we could have cam/ata/* which uses atapi ccb's and ata disk info. Then you have cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code then gets requests sent to it in atapi format and/or something suitable for ata disks. This approach is quite efficient and you get to use the common queueing, error recovery, etc etc stuff. You don't have to do ccb translation or anything. You get your own disk, tape, cd etc driver with their own names and major numbers. They would look *very* similar to the scsi counterparts but would be seperate as they use different ccbs, different backend-specific hooks, etc. Things like umass, vpo etc have it easy since they basically bulk send the scsi ccb's to the device as they use the scsi protocol directly. The ATAPI protocol is similar but would require translation if it used the common top end drivers. So, it either requires different top end drivers or has to do translation. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IBM-DJNA drives on FreeBSD
It seems Peter Wemm wrote: Well, CAM ATAPI is "fairly" easy, the only problem being all the little details that are different enough to make it non-trivial to maintain. I once sat down and tried to get all the details on how the CCB's where different, and decided that I wouldn't want to engage in that. Another story is ATA disks, there you either have to teach CAM about a new lowlevel protocol, or write a SCSIATA translator, which I also decided I didn't want to do... Well, that's assuming you use scsi ccb's... you could use atapi ccb's. We have cam/* which is the generic transport handler. cam/scsi/* which is the scsi peripheral drivers that use scsi ccbs, and then we could have cam/ata/* which uses atapi ccb's and ata disk info. Then you have cam/ata/ata_ad.c, cam/ata/atapi_cd.c etc. Your backend ata controller code then gets requests sent to it in atapi format and/or something suitable for ata disks. This approach is quite efficient and you get to use the common queueing, error recovery, etc etc stuff. You don't have to do ccb translation or anything. You get your own disk, tape, cd etc driver with their own names and major numbers. They would look *very* similar to the scsi counterparts but would be seperate as they use different ccbs, different backend-specific hooks, etc. Uhm, yes, agreed, but it defies some of the gains (ie common highlevel drivers) but would probably keep the performance of the current approach. It would make life a wee bit less complicated, but one would still have to do all the lowlevel code to deal with queing etc, but the higherlevel stuff could probably be shared, maybe CAM would have to be modified a bit but it should be possible... Things like umass, vpo etc have it easy since they basically bulk send the scsi ccb's to the device as they use the scsi protocol directly. The ATAPI protocol is similar but would require translation if it used the common top end drivers. So, it either requires different top end drivers or has to do translation. So its basically a choice between added complexity or added complexity :) When I get all the lowlevel stuff done (this has to be done no matter what approach is chosen) I'll take a look at it again, but if anybody feels like doing anything about it, let me know, so we can get things coordinated -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LDAPed FreeBSD
At 02:29 PM 7/4/99 -0700, Amancio Hasty wrote: Record locking and batch requests is a bit more difficult to solve perhaps someone in the list can shed light into this problem for instance does LDAPv3 provide such mechanism? LDAP (v2 or v3) does not provide record locking, client/server transactions, nor any specific batching requests. The "L" in LDAP means lightweight. I think LDAP-based directory service could be used to manage a wide variety of system information including configuration information for various other network services. However, using LDAP directory services to manage network-services state information is likely not appropriate application of LDAP. For example, while it may make sense to use an LDAP directory service to manage the configuration and master zone information for a Domain Name Service, it would not be wise to use an LDAP directory service to maintain state information (such records created due to DHCP operations) of Domain Name Service. If there any bugs in the ldap server I will probably fix them or better yet the people working on openldap will fix them. OpenLDAP, like FreeBSD, is user maintained and developed. All users are encouraged to contribute to the project. We can surely use your help! Kurt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Strange CPU name reported on my k6-II system
When I take a closer look at dmesg output I discovered that my k6-II reported as "\^M". Maybe it is because I have an very first stepping (I bought my CPU shortly after k6-II appeared on market). Maserboard used - Tyan Trinity 100AT (VIA MP3 chipset). Any ideas? Timecounter "i8254" frequency 1193026 Hz CPU: \^E (300.64-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping=0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX AMD Features=0x808009bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SYSCALL,MMX,3DNow! Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 64M bytes Write Allocate 15-16M bytes: Enable Regards, Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange CPU name reported on my k6-II system
"Mark J. Taylor" wrote: You didn't include the FreeBSD version in your email. I'd bet that it is earlier than 3.2. Get the 3.2 boot floppy and see what it indicates (ftp://ftp.freebsd.org/pub/FreeBSD/3.2-RELEASE/floppies/kern.flp). This buglet was supposedly corrected in January. Unfortunately you are wrong here. When I writing in the -current list it is mean that I'm running -current on my box (cvsup'ed and builded hour ago). Maxim Sobolev wrote: When I take a closer look at dmesg output I discovered that my k6-II reported as "\^M". Maybe it is because I have an very first stepping (I bought my CPU shortly after k6-II appeared on market). Maserboard used - Tyan Trinity 100AT (VIA MP3 chipset). Any ideas? Timecounter "i8254" frequency 1193026 Hz CPU: \^E (300.64-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping=0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX AMD Features=0x808009bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SYSCALL,MMX,3DNow! Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 64M bytes Write Allocate 15-16M bytes: Enable To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha kernel build failure (w/patch)
On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: +#ifdef __i386__ sc-wb_btag = I386_BUS_SPACE_IO; +#endif +#ifdef __alpha__ + sc-wb_btag = ALPHA_BUS_SPACE_IO; +#endif Just curious, but is there a reason that these lines aren't simply sc-wb_btag = BUS_SPACE_IO; with this macro being set to the correct machine-specific one in some appropriate header file? I'm sure I'm missing something... Thanks! -- Parag Patel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha kernel build failure (w/patch)
[trimmed -alpha from cc: list to keep the cross posting police from coming after me :)] On Mon, 5 Jul 1999, Parag Patel wrote: # On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: # +#ifdef __i386__ # sc-wb_btag = I386_BUS_SPACE_IO; # +#endif # +#ifdef __alpha__ # +sc-wb_btag = ALPHA_BUS_SPACE_IO; # +#endif # # Just curious, but is there a reason that these lines aren't simply # # sc-wb_btag = BUS_SPACE_IO; # # with this macro being set to the correct machine-specific one in some # appropriate header file? I'm sure I'm missing something... I wondered that as well. For both the i386 and alpha port the definitions end up in /usr/include/machine/bus.h and stripping off the arch-specific prefix shows that their value is the same. In fact they appear to be the only #define in bus.h with the arch-specific prefix besides the multiple-inclusion #defines. I think they could be combined, but defer the decision (commit) to the folks working on the new bus code as they know their way around this code much better than I do. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha kernel build failure (w/patch)
Of all the gin joints in all the towns in all the world, Steve Price had to walk into mine and say: [trimmed -alpha from cc: list to keep the cross posting police from coming after me :)] On Mon, 5 Jul 1999, Parag Patel wrote: # On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: # +#ifdef __i386__ #sc-wb_btag = I386_BUS_SPACE_IO; # +#endif # +#ifdef __alpha__ # + sc-wb_btag = ALPHA_BUS_SPACE_IO; # +#endif # # Just curious, but is there a reason that these lines aren't simply # # sc-wb_btag = BUS_SPACE_IO; # # with this macro being set to the correct machine-specific one in some # appropriate header file? I'm sure I'm missing something... I wondered that as well. For both the i386 and alpha port the definitions end up in /usr/include/machine/bus.h and stripping off the arch-specific prefix shows that their value is the same. In fact they appear to be the only #define in bus.h with the arch-specific prefix besides the multiple-inclusion #defines. I think they could be combined, but defer the decision (commit) to the folks working on the new bus code as they know their way around this code much better than I do. The reason it's not done that way is because the bus_space code is incomplete. The NetBSD code from which it was taken has a routine that sets up the bus tag for you (and I think the handle too) based on the actual bus type. In other words, you're supposed to be passed a handle to the bus on which your device resides, and you pass that to bus_space_create() or whatever, and it figures out all the right machine specific details for you. Why don't we have this routine? Because we don't have the NetBSD bus architecture and at the time we only ran on the i386 arch, so we took a shortcut and fiddled with the bus space handle and bus space tag directly. If we're really lucky then some day this will get fixed correctly, by somebody who is not me, as I have plenty of other things to keep me busy. -Bill -- = -Bill Paul(212) 854-6020 | System Manager, Master of Unix-Fu Work: [EMAIL PROTECTED] | Center for Telecommunications Research Home: [EMAIL PROTECTED] | Columbia University, New York City = "It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness" = To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent current misreports scsi disk size
Hello I just cvsupped the src-all, built the world, kernel and noticed that: changing root device to da0s1a da0 at ncr0 bus 0 target 5 lun 0 da0: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ncr0 bus 0 target 6 lun 0 da1: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) ^ Actually the size is around 4GB. -- Vallo Kallaste [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: loads of SetAttrs in cvsup of cvs repo
As Jeroen Ruigrok/Asmodai wrote ... * Mark Huizer ([EMAIL PROTECTED]) [990705 02:47]: I did change the cvsup server some time ago, but I'm now back at cvsup.nl.FreeBSD.org hey! that's my queue! when did it start to happen? If it was last week, then there might have been some cause in the upgrading of the machine to 3.2, or it might involve softupdates. That was once last week, which made sense to me after you told me you upgraded cvsup.nl. I think Wilko must have suffered from the same `problem'. Hmm. Well, I'm not sure, but I'll watch my cvsups a bit more. -- | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent current misreports scsi disk size
Vallo Kallaste wrote... Hello I just cvsupped the src-all, built the world, kernel and noticed that: changing root device to da0s1a da0 at ncr0 bus 0 target 5 lun 0 da0: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ncr0 bus 0 target 6 lun 0 da1: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) ^ Actually the size is around 4GB. The change made to scsi_da.c in revision 1.28 doesn't quite work right for disks over 2G on 32 bit machines. You can probably revert back to scsi_da.c version 1.27 and fix the problem. Instead of this: (((unsigned long) dp-secsize) * ((unsigned long) dp-sectors)) 20ul, The calculation might work better as something like this: (((u_int64_t)dp-secsize) * ((u_int64_t) dp-sectors)) 20 That'll probably cause a printf format warning, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent current misreports scsi disk size
Sorry, I pooched it. I'll fix. On Mon, 5 Jul 1999, Kenneth D. Merry wrote: Vallo Kallaste wrote... Hello I just cvsupped the src-all, built the world, kernel and noticed that: changing root device to da0s1a da0 at ncr0 bus 0 target 5 lun 0 da0: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da0: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) da1 at ncr0 bus 0 target 6 lun 0 da1: QUANTUM VIKING II 4.5WSE 5520 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 16, 16bit), Tagged Queueing Enabled da1: 254MB (8910423 512 byte sectors: 255H 63S/T 554C) ^ Actually the size is around 4GB. The change made to scsi_da.c in revision 1.28 doesn't quite work right for disks over 2G on 32 bit machines. You can probably revert back to scsi_da.c version 1.27 and fix the problem. Instead of this: (((unsigned long) dp-secsize) * ((unsigned long) dp-sectors)) 20ul, The calculation might work better as something like this: (((u_int64_t)dp-secsize) * ((u_int64_t) dp-sectors)) 20 That'll probably cause a printf format warning, though. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: LDAPed FreeBSD
Again, I think it is appropiate to use LDAP for configuring network services such as DHCPD , DNS , PPP, etc and to a limited extend sendmail -- see sendmail's modification to support user's delivery address : http://www.stanford.edu/~bbense/Inst.html and actually We can ask the Standford team about some of the problems mentioned on this list to see what they think about it ;specially, if their LDAP service is deployed ... True LDAP (v2 or v3) does not provide record locking . Now the question is does Novell's NDS 8 -- a native LDAP v3 -- , Oracle's Directory Server or Microsoft Active Directory does if they do then how ? Mantaining state information such as DNS is not a good idea as Kurt has stated . Again my emphasis is on configuring network services or other system services if appropiate and to provide a HTML interface which is sufficiently rich to be user friendly. My little test bed project is coming along fine . My servlet which implements my dummy html interfface, http://www.star-gate.com/dhcpd.html, is fully operational and it was not hard to wirite whats left is to provide error checking and cross data validation . The mods to dhcpd to support ldap are already in place. Searching the LDAP database for existing DHCPD entries is also fairly straight forward and I do have a servlet to locate dhcpd servers which accepts regular expressions as suppported by LDAP --- search : www* will locate all the dhcdp servers starting with www 8) Regards At 02:29 PM 7/4/99 -0700, Amancio Hasty wrote: Record locking and batch requests is a bit more difficult to solve perhaps someone in the list can shed light into this problem for instance does LDAPv3 provide such mechanism? LDAP (v2 or v3) does not provide record locking, client/server transactions, nor any specific batching requests. The "L" in LDAP means lightweight. I think LDAP-based directory service could be used to manage a wide variety of system information including configuration information for various other network services. However, using LDAP directory services to manage network-services state information is likely not appropriate application of LDAP. For example, while it may make sense to use an LDAP directory service to manage the configuration and master zone information for a Domain Name Service, it would not be wise to use an LDAP directory service to maintain state information (such records created due to DHCP operations) of Domain Name Service. If there any bugs in the ldap server I will probably fix them or better yet the people working on openldap will fix them. OpenLDAP, like FreeBSD, is user maintained and developed. All users are encouraged to contribute to the project. We can surely use your help! Kurt -- Amancio Hasty [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HELP!!! -CURRENT libtool problem.
Hi. I've finally installed FreeBSD 4.0 and to tell you the truth, I'm not very impressed. I was expecting some bugs but not like that... I don't see a problem with FreeBSD 4.0 so much as a problem with someone jumping beyond their abilities. :) Please, go back to 3.2-STABLE. 4.0-CURRENT is a *development* version and you're expected to understand how to deal with things like applications breakage (including how to recompile libtool and any other components you may need) before doing anything as rash as running 4.0-current. I'm also sure this response will probably scare a few people off and garner stern rebukes from the newbie hand-holding folks, but it's honestly always been the case that -current is NOT for anyone but the advanced class students and we like it that way because we'd otherwise spend more time coaching people over the bumps than we did in actually working on -current and evolving FreeBSD significantly at all. Think of -current as an operating room where surgeons are actively working on a patient under anaesthesia - do you really want just anybody wandering in there to ask the doctors random questions while they work or do you maybe want to limit participation to only those with some prior medical training? I also make this point now and with such force because various signs and portents indicate that -current is about to become a dangerous place again for awhile, and a lot of people who really don't have the cojones to run -current are going to find this out rather abruptly and painfully. :-) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha kernel build failure (w/patch)
Parag Patel wrote: On Mon, 05 Jul 1999 00:33:57 CDT, Steve Price wrote: +#ifdef __i386__ sc-wb_btag = I386_BUS_SPACE_IO; +#endif +#ifdef __alpha__ +sc-wb_btag = ALPHA_BUS_SPACE_IO; +#endif Just curious, but is there a reason that these lines aren't simply sc-wb_btag = BUS_SPACE_IO; with this macro being set to the correct machine-specific one in some appropriate header file? I'm sure I'm missing something... Thanks! The really annoying thing is that this is handled in the bus configuration system already. The driver only has to ask for the handle and tags for the resource it's activated and can then use that directly for the bus_space calls. But, old style drivers don't have access to that as the information is not available across the compatability shims. -- Parag Patel Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel versions and kld modules [WAS: this of interest to anyone?]
On Sat, 3 Jul 1999, Peter Wemm [EMAIL PROTECTED] writes: A few key suggestions for people still along for the ride: 1: When you've got a good running kernel that you're happy with, do yourself a big favour and copy it from /kernel to /kernel.ok or something like that. So, when you manage to get a bad /kernel and /kernel.old, you've still got a fallback that doesn't mean resorting to a fixit disk boot. This reminds me of something I wanted to ask about. A little while back I made the typical junior mistake of building/installing a new kernel without doing the make install of the related modules. In my case, the crash came from kernfs and it was easy to boot single-user and comment out a line in fstab. But my question is with the trend towards more module-ization of the kernel, does saving a /kernel.old make sense without saving a /modules.old? Should the config-generated Makefile for the kernel have a target to build and install the new modules as well (as opposed to installing them with make world)? Should we install modules into some path identified by a kernel version (whatever that means exactly)? The extreme end of this line of logic is the Linux module hashing mechanism, which I've never fully understood. My experience with it is that it can prevent you from using a binary-only module (AFS is the one I'm thinking of) even if the interfaces haven't really changed. It seems like a poor substitute for proper management and versioning of kernel interfaces. I suppose much of this becomes a non-issue outside of -current, and maybe that's why no one has seemed worried about it. Even in -stable, though, I suppose you could have incompatible kernel interfaces introduced that might break modules. It just seems to me that one should consider /kernel plus /modules/* to be more of unit. Thanks for any insights. Tom Pavel Stanford Linear Accelerator Center [EMAIL PROTECTED] http://www.slac.stanford.edu/~pavel/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha kernel build failure (w/patch)
In message [EMAIL PROTECTED] Bill Paul writes: : If we're really lucky then some day this will get fixed correctly, : by somebody who is not me, as I have plenty of other things to keep : me busy. I'm working on moderizing the bus space implementation right now. It will make writing the newconfig shims for new-bus easier. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: alpha kernel build failure (w/patch)
Steve Price writes:
}
+#ifdef __i386__
sc-wb_btag = I386_BUS_SPACE_IO;
+#endif
+#ifdef __alpha__
+ sc-wb_btag = ALPHA_BUS_SPACE_IO;
+#endif
#else
if (!(command PCIM_CMD_MEMEN)) {
Just a minor comment.. anytime you have something like this, it's
always nice to do it this way instead:
#if defined(__i386__)
sc-wb_btag = I386_BUS_SPACE_IO;
#elif defined(__alpha__)
sc-wb_btag = ALPHA_BUS_SPACE_IO;
#else
#error Machine architecture unsupported
#endif
That way when somebody wants to add M68K support or whatever they
are alerted that they need to implement the new flag at compile
time instead of at panic time :-)
-Archie
___
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Kernel versions and kld modules [WAS: this of interest to anyone?]
On Monday, 5 July 1999 at 15:42:13 -0700, Tom Pavel wrote: On Sat, 3 Jul 1999, Peter Wemm [EMAIL PROTECTED] writes: A few key suggestions for people still along for the ride: 1: When you've got a good running kernel that you're happy with, do yourself a big favour and copy it from /kernel to /kernel.ok or something like that. So, when you manage to get a bad /kernel and /kernel.old, you've still got a fallback that doesn't mean resorting to a fixit disk boot. This reminds me of something I wanted to ask about. A little while back I made the typical junior mistake of building/installing a new kernel without doing the make install of the related modules. In my case, the crash came from kernfs and it was easy to boot single-user and comment out a line in fstab. But my question is with the trend towards more module-ization of the kernel, does saving a /kernel.old make sense without saving a /modules.old? Should the config-generated Makefile for the kernel have a target to build and install the new modules as well (as opposed to installing them with make world)? Should we install modules into some path identified by a kernel version (whatever that means exactly)? You've come up with a point I've been wanting to make for some time. The kernel build should really build the modules as well, and the install should change things as you suggest. Of course, that takes up more space, but I believe it's necessary. I suppose much of this becomes a non-issue outside of -current, Not really. Less of an issue, yes, but it's still there. Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Earn Cash
Dear Webmaster, We are a business conducting business and this is not unsolicited bulk email. We have purchased your email address from an Internet marketing center. If you do not wish to receive further notices from Lucky's Casino, please reply to this e-mail and type "UNSUBSCRIBE" in the subject field. Want to earn extra cash? Join the Lucky's Casino affiliate program to earn revenues from your website. By participating in this mutually beneficial program, webmasters like your-self will get the opportunity to earn extra cash and become a part of the fastest growing industry in the world. Need more Info? If you are interested in becoming an affiliate of Lucky's Casino, and would like to find out more about this program, please visit: http://207.236.72.231/TrackA.asp Please let us know if you have any comments or questions by e-mailing us at [EMAIL PROTECTED] Regards, The Staff at Lucky's We hope you have a great day! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Earn Cash
Luckycasino.com now blocked by spam filters. Sorry, as always, for the interruption. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HELP!!! -CURRENT libtool problem.
Also, before I removed 3.2 from my system, I made a little cpp hello world program and with GCC the binary was 8k. That same program was 40k with EGCS. Anyone know why? Look at the ``ldd'' output. libstdc++ is statically linked if you used the egcs port (which if you did this on 3.2 you must have). -- -- David([EMAIL PROTECTED] -or- [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange CPU name reported on my k6-II system (fwd)
Thanks. Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ -- Forwarded message -- Date: Tue, 06 Jul 1999 09:35:18 +0300 From: Maxim Sobolev [EMAIL PROTECTED] To: Brian F. Feldman [EMAIL PROTECTED] Subject: Re: Strange CPU name reported on my k6-II system You are probably forget to send this reply to [EMAIL PROTECTED] -Maxim "Brian F. Feldman" wrote: On Tue, 6 Jul 1999, Greg Lehey wrote: On Monday, 5 July 1999 at 20:13:57 +0300, Maxim Sobolev wrote: When I take a closer look at dmesg output I discovered that my k6-II reported as "\^M". Maybe it is because I have an very first stepping (I bought my CPU shortly after k6-II appeared on market). Maserboard used - Tyan Trinity 100AT (VIA MP3 chipset). Any ideas? Timecounter "i8254" frequency 1193026 Hz CPU: \^E (300.64-MHz 586-class CPU) Origin = "AuthenticAMD" Id = 0x580 Stepping=0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX AMD Features=0x808009bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SYSCALL,MMX,3DNow! Data TLB: 128 entries, 2-way associative Instruction TLB: 64 entries, 1-way associative L1 data cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative L1 instruction cache: 32 kbytes, 32 bytes/line, 2 lines/tag, 2-way associative Write Allocate Enable Limit: 64M bytes Write Allocate 15-16M bytes: Enable I believe green was doing some work in this area in the last day or two. Yes, I committed some K6-related things. See that AMD Features line? Closed a PR while I was at it, since that was the commit. The code is pretty much just how I would have done it, although MAYBE I'd move it into the default. Anyway, here's the thing: this has been reported before. I need to know if it's the same person. If not, then it seems Stepping 0 has this bug. I don't know why the CPU is doing this, but I know what it's doing. AMDs of a certain stepping and greater will name themselves. i.e. CPU: AMD-K6(tm) 3D processor (350.81-MHz 586-class CPU) That's my K6-2, a K6-(tm) 3D. Now, we're getting this from the CPU's registers after a specific call. If I can find out a specific stepping of this CPU exhibits this behavior, perhaps it's a bug that was fixed later on. Would those of you with K6-2's that are either: 1. Stepping=0 (Id = 0x580) or 2. Noticing strange CPU names please contact me? Greg -- See complete headers for address, home page and phone numbers finger [EMAIL PROTECTED] for PGP public key Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ -- "We believe in the Power and the Might!" (Manowar, 1996) Maxim V. Sobolev, Financial Analyst, Vega International Capital Phone: +380-(44)-246-6396 Fax: +380-(44)-220-8715 E-mail: [EMAIL PROTECTED] ICQ: #42290709 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
