Re: multiple cd devices
On Fri, 31 Dec 1999, Chuck Robey wrote: On Fri, 31 Dec 1999, Brian Fundakowski Feldman wrote: The way certain devices, like cd with its monotonically increasing counter where devices are probed in order and assigned device based on precedence and not hardwiring/controller connection, work is consistent between the kernel and MAKEDEV. If you have 2 cd devices, you have cd0 and cd1, so MAKEDEV accepts "cd2" for "two cd devices". All CD devices work that way. Disks don't, because there is potential for hard-wiring there, and will often be gaps. Why are "certain" devices wildly different than all other ones? I've never encountered that kind of syntax before, and I can't see that it's documented anywhere at all. Certainly, MAKEDEV itself (in it's comments) treats cd* just like all the others, specifying that the number following is a unit number, and *not* a quantity. I don't know when this happened, but it's surely not obvious. Not one word in the handbook, either. In fact, according to cd(4), you *can* specify the unit number: ... Prior to FreeBSD 2.1, the first device found will be attached as cd0 the next, cd1, etc. Beginning in FreeBSD 2.1 it is possible to specify what cd unit a device should come on line as; refer to scsi(4) for details on kernel configura- tion. That makes this odd setup even odder. Can't understand why this was done. FWIW, bin/13768 asks the same questions. - Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ida driver in -current and eisa bus attachment
i wonder what is happening to the ida driver for comapq's smart array controller series. people say the pci version works but the eisa version is not. in the ida.c file is says: * Specific probe routines are in: * pci/ida_pci.c * i386/eisa/ida_eisa.c but unfortunatly the ida_eisa.c file seems to be missing in the source tree (i just cvsuped the whole thing). i did some research at deja and found out, that matthew dodd wrote the eisa bus attachment and it is downloadabe on his ftp site. unfortunatly (again) the eisa_add_intr() routine has changed and needs an additional argument (which happend to be the irq-trigger). i added EISA_TRIGGER_LEVEL to that call (level is what the controller uses according to the compaq bios). the kernel compiles but crashes with a trap 12 when probing ida0. it crashed in the ida_wait() routine in ida.c while initially trying to attach the board. i wonder if anybody else hat such problems and (that would be even better) has solved them. i am willing to help in developting this driver but my knowlegde of c is bad and my kernel programming excperiences are even worse ... :-( anyways, i hope somebody out there is still working on that thing, regards, oliver -- And remember: "Life sucks and then you die!" email: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! - Save this lifeform ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
date(1) and -v-1m
Hello! The behaviour of date(1) is probably specified by POSIX, but I think, date -v-1m should at least return a date a month _before_ the current month. Example: Mi 1 Dez 1999 15:06:47 CET (Dez. has 31, so it should be Nov 30, I think). More confusing is something like: alex:~ $ date -v-1m +%Y-%m 1999-12 what I wanted to use to create backup folders for my mail-system (all mails of the last month are moved to a folder of the last month). That's weird, somehow. Is this a bug or a feature? Is this POSIX-compilant? Do we want an additional option? (I want :-)) Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multiple cd devices
On Fri, 31 Dec 1999, Chuck Robey wrote: On Fri, 31 Dec 1999, Brian Fundakowski Feldman wrote: The way certain devices, like cd with its monotonically increasing counter where devices are probed in order and assigned device based on precedence and not hardwiring/controller connection, work is consistent between the kernel and MAKEDEV. If you have 2 cd devices, you have cd0 and cd1, so MAKEDEV accepts "cd2" for "two cd devices". All CD devices work that way. Disks don't, because there is potential for hard-wiring there, and will often be gaps. Why are "certain" devices wildly different than all other ones? I've never encountered that kind of syntax before, and I can't see that it's documented anywhere at all. Certainly, MAKEDEV itself (in it's comments) treats cd* just like all the others, specifying that the number following is a unit number, and *not* a quantity. I don't know when this happened, but it's surely not obvious. Not one word in the handbook, either. *shrug* This is the only rationality I could think of. Obviously, this breaks POLA, so it should be changed (with ample warning). In fact, according to cd(4), you *can* specify the unit number: ... Prior to FreeBSD 2.1, the first device found will be attached as cd0 the next, cd1, etc. Beginning in FreeBSD 2.1 it is possible to specify what cd unit a device should come on line as; refer to scsi(4) for details on kernel configura- tion. That makes this odd setup even odder. Can't understand why this was done. So maybe it's just hysterical raisins. I'm not saying I like the behavior, just that I understand what that MAKEDEV behavior is. Chuck Robey| Interests include C Java programming, New Year's Resolution: I | electronics, communications, and will not sphroxify gullible| signal processing. people into looking up | I run picnic.mat.net: FreeBSD-current(i386) and fictitious words in the| jaunt.mat.net : FreeBSD-current(Alpha)| dictionary.| -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ida driver in -current and eisa bus attachment
i wonder what is happening to the ida driver for comapq's smart array controller series. Work on this driver is stalled owing to the fact that nobody that can and wants to work on it has access to the Compaq hardware required. You can't use these controllers except in Compaq systems, which makes things very difficult. If someone has a complete system featuring one or more of these controllers (a mixed PCI/EISA system would be best), there are several people that could put it to good use. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multiple cd devices
Bruce Evans wrote: On Fri, 31 Dec 1999, Chuck Robey wrote: Why are "certain" devices wildly different than all other ones? I've Because the CAM update broke (SCSI) cd devices in rev.1.171 of MAKEDEV. mcd and scd were in the same case statement so they were broken too. The breakage has spread to acd and ccd (although the latter is not a cdrom), but not to matcd or wcd or non-cdrom disks. What about having ./MAKEDEV cd0 cd1 cd4 -da2 da6-da9 create cd0, cd1, cd4, da1, da2, da6, da7, da8, da9 ? This would be a generic solution that still allows for holes. Not possible because of compatibility issues? I'm willing to give it a go. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Interesting read: http://www.vcnet.com/bms/ JLF To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: multiple cd devices
"Jeroen C. van Gelderen" wrote: Bruce Evans wrote: On Fri, 31 Dec 1999, Chuck Robey wrote: Why are "certain" devices wildly different than all other ones? I've Because the CAM update broke (SCSI) cd devices in rev.1.171 of MAKEDEV. mcd and scd were in the same case statement so they were broken too. The breakage has spread to acd and ccd (although the latter is not a cdrom), but not to matcd or wcd or non-cdrom disks. What about having ./MAKEDEV cd0 cd1 cd4 -da2 da6-da9 create cd0, cd1, cd4, da1, da2, da6, da7, da8, da9 ? This would be a generic solution that still allows for holes. Not possible because of compatibility issues? I'm willing to give it a go. "Send patches" :-) Seriously, the ultimate solution is a devfs-like system. 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
xntpd - VERY old folks, how about updating? :-)
This is not a port, its part of the RELEASE! Its several YEARS old, and doesn't work right - you get lots of STEP changes instead of what you SHOULD get, which is a slew on the system clock. The new code (which has a current release date of this month) DOES appear to work correctly (I'm still verifying it, but it's certainly better than what is in the tree right now!) What does (someone) need to do to get this changed out/updated? I can't send it in as a port, since its part of the base package (setting it up as a port would be pretty trivial from what I can see) -- -- Karl Denninger ([EMAIL PROTECTED]) Web: http://childrens-justice.org Isn't it time we started putting KIDS first? See the above URL for a plan to do exactly that! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
