Re: HEADS-UP: Shared Library Versions bumped...
Quoting Ken Smith : First I want to apologize. This should have happened a bit sooner in our release cycle than now. To be honest I had slipped into "We have symbol versioning for our libraries now" mode. But only a few of the libraries currently have that turned on and I sorta forgot we still need to deal with all the shared libraries that do not have symbol versioning enabled yet. Sorry for the hassle this will cause. ...snip... Wouldn't this be a great opportunity to fix kern/133926 by bumping up the max username length? -- Chris Dillon - NetEng/SysAdm Reeds Spring R-IV School District Technology Department 175 Elementary Rd. Reeds Spring, MO 65737 Voice: 417-272-8266 Fax: 417-272-0015 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ZFS on top of GELI / Intel Atom 330 system
Quoting Dan Naumov : Ouch, that does indeed sounds quite slow, especially considering that a dual core Athlon 6400 is pretty fast CPU. Have you done any comparison benchmarks between UFS2 with Softupdates and ZFS on the same system? What are the read/write numbers like? Have you done any investigating regarding possible causes of ZFS working so slow on your system? Just wondering if its an ATA chipset problem, a drive problem, a ZFS problem or what... I recently built a home NAS box on an Intel Atom 330 system (MSI Wind Nettop 100) with 2GB RAM and two WD Green 1TB (WD10EADS) drives in a mirrored ZFS pool using a FreeNAS 0.7 64-bit daily build. I only see 25-50MB/sec via Samba from my XP64 client, but in my experience SMB always seems to have horrible performance no matter what kind of servers and clients are used. However, dd shows a different set of figures: nas:/mnt/tank/scratch# dd if=/dev/zero of=zero.file bs=1M count=4000 4000+0 records in 4000+0 records out 4194304000 bytes transferred in 61.532492 secs (68164052 bytes/sec) nas:/mnt/tank/scratch# dd if=zero.file of=/dev/null bs=1M 4000+0 records in 4000+0 records out 4194304000 bytes transferred in 33.347020 secs (125777476 bytes/sec) 68MB/sec writes and 125MB/sec reads... very impressive for such a low-powered box, I think, and yes the drives are mirrored, not striped! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Analysis of disk file block with ZFS checksum error
Quoting Joe Peterson <[EMAIL PROTECTED]>:
I dumped the whole bad section as a string, and here's (partly) what I get:
[...edited for brevity...]
@$${138B8B{@
<(21470=Thu Jan 24 23:20:58 2008)>
[117:^80(^91^21470)]
@$$}138B8B}@
@$${138C18{@
<(21472=1201242069)>[-2:^80(^82^85)(^83^1B5)(^84=b)(^85=1)(^86=0)(^87=0)
(^88=0)(^89^2146C)(^8A=)(^8B=40)(^8C=2e)(^8D^84)(^8E=0)(^90^21472)
(^91^21460)]
@$$}138C18}@
@$${138C19{@
<(21473=a72f78)>[2:^80(^89^21473)]
@$$}138C19}@
@$${138C1A{@
@$$}138C1A}@
and more of the same. Note the date string. There are several like
that. Anyone recognize this text format?
That is a chunk of a Mozilla Mork-format database. Perhaps the
Firefox URL history or address book from Thunderbird.
--
Chris Dillon - NetEng/SysAdm
Reeds Spring R-IV School District
Technology Department
175 Elementary Rd.
Reeds Spring, MO 65737
Voice: 417-272-8266 Fax: 417-272-0015
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: quota and snapshots in 6.1-RELEASE
Quoting Mike Jakubik <[EMAIL PROTECTED]>: IIRC, there are some quota and snapshots changes merged in 6.1-STABLE after 6.1-RELEASE is releases. So I think you may want to try that. Thats correct. I have been meaning to test these, but not had the time to do so yet. If you can, update to -STABLE and give it a test. I have been running the fixes without problems since this weekend, but I was only bitten by the previous bugs maybe once or twice a week, even though I used snapshots and quotas extensively. If my system manages to stay up at least two weeks it is most likely fixed. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: quota deadlock on 6.1-RC1
Quoting Kris Kennaway <[EMAIL PROTECTED]>: On February 21 -- that is over 2 months ago -- I sent email to this list containing a fix for the quota deadlocks that were known at the time. I got minimal response from users, but it was uniformly positive. The fix was committed, and the status of the "quota deadlocks" item on the 6.1-RELEASE todo list was changed from "must fix" to "believed fixed, please test". The next I heard about the problem was about a week ago when someone reported another deadlock and several others chimed in with "oh yeah, it still deadlocks for me too". Well, sorry folks, you should have told me in February. Or if you only found out about the problem a week ago, you need to recognize that problems raised at the last minute cannot always be fixed instantly. I was one of those others who said "me too". :-) Although I subscribe to every FreeBSD mailing list, I usually just glance over all of the subject lines until something catches my eye. So, unfortunately, I apparently missed that whole bit and it wasn't until a particular subject caught my eye recently that I thought it might be addressing the same problem I had. I hadn't mentioned the problem to the lists before because I had zero diagnostic information about it and it was a production box that I couldn't fool around with too much, so I had found a workaround (daily reboot) a long time ago and didn't think much more about it. Although I recently compiled the kernel with various debug options (WITNESS, DDB, etc.), it takes days for it to recur (without daily reboots) and when it hanged again a couple of nights ago, I completely forgot about trying to break into the debugger and rebooted the box anyway. *slaps forehead* And of course it hasn't happened again, yet. Maybe next time. I'll be happy when we figure out what the problem is and find a fix for it, it doesn't matter to me whether or not it makes it into the 6.1 release. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck_ufs locked in snaplk
Sorry Dmitry, you'll get this again since I forgot to reply to the list the first time. Quoting Dmitry Morozovsky <[EMAIL PROTECTED]>: On Tue, 25 Apr 2006, Kris Kennaway wrote: KK> What people are seeing now must be some other problem that I wan't KK> able to reproduce. KK> KK> Once I hear back from someone who can reproduce it with debugging KK> enabled (I'm also trying) we can try to fix it. Please try to simulate user who is over soft quota and is out of grace period. I'm trying to do so as well, but currently quite busy with other tasks :( Hmm, this may very well be the key because I have about 3 users that are now over soft block quota and are out of grace time. I would also wager that at least a couple of users exceed soft quota and possibly even hit the hard quota on a daily basis for short enough periods of time that I don't notice. That may also explain why with no system changes over the past 20+ days that I suddenly had problems this last weekend, since quota changes constantly. I'll have the debug setup in place this evening, I hope. I know I said I would do it last night, but, well, it didn't happen. :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck_ufs locked in snaplk
Quoting Kostik Belousov <[EMAIL PROTECTED]>: I'm going to update to the latest 6.1 code this evening and enable INVARIANTS, WITNESS, and the two DEBUG_LOCKS options to the kernel to see if it catches anything. Please, also add DDB to the kernel and show the result of the show lockedvnodes alltrace ps in the DDB after the deadlock, as asked by Kris Kennaway earlier in this thread ! OK, I've added DDB, but all of the information I might gather I'll have to write down by hand since I have no serial console access. :-( ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fsck_ufs locked in snaplk
Quoting Dmitry Morozovsky <[EMAIL PROTECTED]>: On Mon, 24 Apr 2006, Kris Kennaway wrote: KK> Also you should add DEBUG_LOCKS and DEBUG_VFS_LOCKS on the off chance KK> they catch the problem. I got one thought about the source of these hangs/crashes: this machine is the only one with actively used quotas. I'll test the more thoroughly this evening. I had problems with snapshots and hangs in 5.x. For that, a daily reboot would keep the problems at bay. I upgraded to 6.0 and the problems completely disappeared. I kept 6.0-STABLE running for weeks. Somewhere along the line, as 6.1 approached, similar problems re-appeared, but not exactly the same as what I had in 5.x. Now instead of a complete system hang, individual processes will hang while attempting to access a certain filesystem. I'm running 6.1-PRERELEASE from April 2 and for some reason since this weekend it has happened more often, but I'm not sure why since I haven't made any system changes since April 2. I also am using quotas heavily with this system, and snapshoting every filesystem once a day. The filesystem which processes will hang on when attempting to access it happens to be the one with quotas enabled. I'm going to update to the latest 6.1 code this evening and enable INVARIANTS, WITNESS, and the two DEBUG_LOCKS options to the kernel to see if it catches anything. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to make ipfw consider MAC-IP match?
On Tue, 15 Feb 2005, Artem Kuchin wrote: Chris Dillon <[EMAIL PROTECTED]> wrote: On Mon, 14 Feb 2005, Artem Kuchin wrote: I have a table with ethernet (MAC) addresses matching IPs. It is used to build dhcp config file. But regardless of that any user can assign his neighbour ips while that pc is turned off and use it to access internet. The local ips are 192.168. and are behind natd. I am running 5.3-STABLE and have heard that ipfw2 can in someway use MAC addresses, but how do I setup ipfw in such a way that it allows certain IP only from one and only one MAC address? I hope you are getting my idea. What you probably want is static ARP entries. arp -s 192.168.1.1 00:11:22:33:44:55 But that still won't stop someone from changing their IP address and MAC address to match, it just makes it harder. To prevent that kind of thing you need to use 802.1x authentication or maybe even PPPoE. Um.. I just have read tutorial about PPPoE and did not find anything about matching IP and MAC addresses. So, if i use PPPoE i still need to do static ARP You wouldn't need or want Static ARP with PPPoE. You do authentication with PPPoE using usernames and encrypted passwords. Therefore no "stealing" unless someone figures out someone else's username and password. (i did not undestrand, how i somebody can match mac and ip with static arp except that he actually get the physical NIC from somebody's computer). Because you can change the MAC address of your NIC to match someone else's very easily. Here's how in FreeBSD: ifconfig fxp0 link 00:11:22:33:44:55 It's that easy... Also, as i see, users on PPPoE can login from any computer and get their IP address.It will not work because of static arp, but still, there are getting their address. And the last thing, if i am to migrate to PPPoE this basically means i will need to give up DHCP, because PPP will serve IPs, not DHCP. Right? Correct. Users don't even have to have static IPs. They can be assigned from a pool of IP addresses by the PPPoE server once they have authenticated. And now the theory question. While i am running pppoe server on some ethernet interface what disallows any user to use that interface as a ip gateway without any pppoe? Just assigned themselves an ip, ignoring pppoe and using the server as a gateway. I am probably missing some point here. You can have the Ethernet interface you are doing PPPoE with also have an IP address and act as a standard gateway if you really want to, which would be good for transitioning purposes until everybody is using PPPoE, but once that is done you can remove the IP address from the interface and PPPoE will be the only choice. -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest, most open, and most stable OS on the planet - Available for IA32, IA64, AMD64, PC98, Alpha, and UltraSPARC architectures - PowerPC, ARM, MIPS, and S/390 under development - http://www.freebsd.org Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to make ipfw consider MAC-IP match?
On Mon, 14 Feb 2005, Artem Kuchin wrote: I have a table with ethernet (MAC) addresses matching IPs. It is used to build dhcp config file. But regardless of that any user can assign his neighbour ips while that pc is turned off and use it to access internet. The local ips are 192.168. and are behind natd. I am running 5.3-STABLE and have heard that ipfw2 can in someway use MAC addresses, but how do I setup ipfw in such a way that it allows certain IP only from one and only one MAC address? I hope you are getting my idea. What you probably want is static ARP entries. arp -s 192.168.1.1 00:11:22:33:44:55 But that still won't stop someone from changing their IP address and MAC address to match, it just makes it harder. To prevent that kind of thing you need to use 802.1x authentication or maybe even PPPoE. -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest, most open, and most stable OS on the planet - Available for IA32, IA64, AMD64, PC98, Alpha, and UltraSPARC architectures - PowerPC, ARM, MIPS, and S/390 under development - http://www.freebsd.org Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: NATD Issue
On Wed, 26 May 2004, Evgeny Ivanov wrote: in rc.conf: natd_enable="YES" natd_flags="-f /etc/natd.conf" You also need: gateway_enable="YES" firewall_enable="YES" Also make sure you're not doing anything silly in ipfw. Use a stock /etc/rc.firewall and set firewall_type="OPEN" in rc.conf to make real sure. in natd.conf: use_sockets yes same_ports yes reverse yes Why do you want 'reverse' enabled? You probably don't want this. interface fxp0 Make sure this is your public interface, not the private one. redirect_address 10.0.1.2 one-external-ip redirect_address 10.0.1.3 two-external-ip -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest, most open, and most stable OS on the planet - Available for IA32, IA64, AMD64, PC98, Alpha, and UltraSPARC architectures - PowerPC, ARM, MIPS, and S/390 under development - http://www.freebsd.org Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
PATCH: conf/34729: treat smbfs as network file system in /etc/rc
I was helping someone on IRC with this problem and created my own patch and was just about to submit it, then checked to make sure nobody had already done the same. Well, someone already has (two years ago!), and the patch exists in conf/34729. It works. Can someone commit this, pretty please? The patch does not change the fstab manual page, however, which probably should be updated to reflect that SMBFS can be treated the same as NFS at startup. -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest, most open, and most stable OS on the planet - Available for IA32, IA64, AMD64, PC98, Alpha, and UltraSPARC architectures - PowerPC, ARM, MIPS, and S/390 under development - http://www.freebsd.org Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ATA driver feature request
On Thu, 24 Jan 2002, SXren Schmidt wrote: > > However, the warning message would be slightly reworded like "non-ATA66 > > compliant cable or second device" > > Good point, I'll get something done about this... Just as a note, it doesn't have to just be the cable or the second device, it can be either one or both or maybe the controller too. :-) I don't remember, but I might actually be using an 80-wire cable here on my box at work (as if it would matter with only an ATA33 controller): atapci0: port 0xf000-0xf00f at device 7.1 on pci0 ad0: 19541MB [39703/16/63] at ata0-master UDMA33 ata0-slave: DMA limited to UDMA33, non-ATA66 compliant cable ad1: 6149MB [12495/16/63] at ata0-slave UDMA33 acd0: CDROM at ata1-master using PIO4 afd0: 96MB [32/64/96] at ata1-slave using PIO0 ata0-master is actually the device that is capable of ATA66 (actually ATA100 I think). I think ata0-slave is only capable of ATA33, but I could be wrong. My system at home with an ATA100-capable drive on a PIIX4 controller doesn't mention anything about a non-compliant cable (though it really is an 80-wire cable, maybe that's why), but it is also the only thing on the bus (I use SCSI for everything else): atapci0: port 0xffa0-0xffaf at device 7.1 on pci0 ad0: 39083MB [79408/16/63] at ata0-master UDMA33 -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
AAARGH. Was: Re: DOH! Something PCI-related recently broken in-STABLE
On Fri, 17 Aug 2001, Chris Dillon wrote: > Sh~t. Now I'm seeing a hang, but its hanging even on a > pre-interrupt-routing kernel I kept. Its completing the boot, and > getting all the way to a login prompt, but it hangs solid just a > few seconds after that. The BIOS upgrade must have caused it. :-( OK... this hang is really weird. Everything is fine as long as I stay in single-user mode. I can ifconfig interfaces, run cvsup, etc. But just seconds after booting multi-user and getting the login prompt, the system hangs solid. I've tried old 4.3 GENERIC kernels, recent kernels, all the same. I've removed everything imaginable from the startup sequence. Nothing in /usr/local/etc/rc.d starting up, nothing on rc.local, I even somehow managed to accidentally delete rc.conf and still it hangs on boot. Made up a new rc.conf with everything disabled that usually gets turned on by default. Even took out all of the tweaks in sysctl.conf. No go. Anyone else seeing this on a Compaq or any other box? -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Constant panics on 4.1-STABLE!
freebsd-bugs removed from Cc On Wed, 20 Sep 2000, Alfred Perlstein wrote: > * Chris Dillon <[EMAIL PROTECTED]> [000920 09:01] wrote: > > On Tue, 19 Sep 2000, BSD wrote: > > > > > Thanks for any help! Oh, and these panics can be as close as 12 > > > minutes and as far apart as 8 days (not the documented ones, but the ones > > > I have had up to this point, with all 3 DIMMs in place). You can see the > > > uptimes for the documented panics at the bottom of the JPEGs. > > > > I hate to tell you this, but this is most certainly a memory problem. > > Get some memory that has been tested and approved by your motherboard > > manufacturer for that board, and to be double-sure, make it ECC memory > > and then enable ECC in the motherboard's BIOS. If you STILL have > > problems after that, then you can start blaming the problem on > > something else. The ONLY other time I have had problems like this is > > when overclocking the processor. You aren't overclocking those > > processors are you? > > Another problem can be heating issues, it doesn't matter how good > your case's cooling is when the surrounding tempatures are too high. Yes, I neglected to mention that. Overheating can cause the same symptoms that overclocking the processor does. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Constant panics on 4.1-STABLE!
On Tue, 19 Sep 2000, BSD wrote: > I'm running 4.1-STABLE on a 700MHz Athlon with a 300W power supply > (only recently did I learn that 250W wasn't enough), a single Maxtor > 40.9GB hard drive (UDMA/66, 7200RPM), an Abit KA7 motherboard, with > normally 768MBs of PC133 RAM (non-ECC). An fxp0 device, and a generic PCI > video card. pci0: at > 13.0 irq 10. There's a floppy drive, and a 2-fan hard drive cooling unit > that mounts in the front of 5.25" slot which houses the maxtor via > mounting brackets. > > Even though 300W is considered the "minimum" by some for Athlon > supplies, I think my minimal hardware should make it a stable option. > > The multiple panics were in the following sequence: > > 1) Server is booted with all DIMMs, on a BP6. PANIC. The BP6 is a pretty solid 440BX based board, so I doubt that is the culprit. FreeBSD has no problems with this board or the PIII you're using on it. It's the memory. > 2) Server is booted with all DIMMS, on a KA7. PANIC. The KA7 is a VIA KX133 based board. I have never found VIA chipsets to be reliable. However, it is probably the memory which is at fault. > 3) Server is booted with DIMMs #2 and #1. PANIC. Crappy memory. > 4) Server is booted with DIMM #1. PANIC. Crappy memory. > 5) Server is booted with DIMM #2. PANIC. Crappy memory. > 6) Server is booted with DIMM #3. PANIC. Crappy memory. > > Anyone interested in helping me out here, can see the panic > messages at the following url. I'll post further panic captures there > too, if they happen. Panics 2-6 are listed in sequence on the website. > > http://24.108.110.119/~eo/panics/ > > Thanks for any help! Oh, and these panics can be as close as 12 > minutes and as far apart as 8 days (not the documented ones, but the ones > I have had up to this point, with all 3 DIMMs in place). You can see the > uptimes for the documented panics at the bottom of the JPEGs. I hate to tell you this, but this is most certainly a memory problem. Get some memory that has been tested and approved by your motherboard manufacturer for that board, and to be double-sure, make it ECC memory and then enable ECC in the motherboard's BIOS. If you STILL have problems after that, then you can start blaming the problem on something else. The ONLY other time I have had problems like this is when overclocking the processor. You aren't overclocking those processors are you? -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Numbering of fxp devices
On Tue, 22 Aug 2000, Fred Clift wrote: > > other way around. The order stayed this way for a couple of weeks during > > which I tracked -stable and made world frequently, but after one > > upgrade, the box came up with the on-board card claiming to be fxp0. > > However, not long afterwards, it reverted to the original behaviour. > > > > Now, obviously the numbering doesn't matter all that much. What _does_ > > matter is if the numbering is unpredictable at boot time (worst case) or > > if it may be reversed after a remote upgrade. Is this down to pure fluke > > or can I lock down the order in some way? > > > I am not directly aware of what recent changes would have caused > the change in probe order, but I can give you some ideas about > where to look and then offer my comments about what I belive would > be ideal. > > in FreeBSD <= 3.X it appears that all pci-to-pci busses were > probed first, and then devices on them were probed in some fixed > order. > > In FreeBSD >= 4.0 the 'newbus' code replaced a lot of the old bus > code including probing and now the buses are probed kind of in a > depth-first fashion, finding all devices on a particular bus and > then moving on to another. Aparently, from your results, the > order that the busses are probed has been changed or something > similar. > > I pitty the guy with whom I exchanged emails a while back that is > running a 6 or 8 port 'router' all with fxp cards. He was running > 3.4 last I knew and was planning on waiting a LONG time before > upgrading to 4.X because of the relative difficulty of figuring > out which cards when where. That would be me, probably. :-) 7 NICs, one of which is dual-port, for a total of 8 ports. I recently moved all of those NICs from a Compaq Proliant 3000 running 3.4-STABLE into a new Proliant ML530 running 4.1-STABLE. The card order is definately weird, but that isn't so much FreeBSD's fault. Compaq was nice enough to label primary, secondary, and tertiary PCI bus slots on the back of the machine, but they aren't in order anyway. What I ended up doing was booting the system with all the cards installed, noting the MAC address of each interface, and then comparing that to physical slot locations. Not as nice as the sequential ordering in the Proliant 3000, but not a big deal either, as long as it doesn't change on me in the future without some warning. :-) > What I would find to be the best of all possible worlds is if you could > wire-down pci-card instances to particular instances of a driver - ie I > want the first card on bus 2 to be fxp0 and the second card on bus 1 to be > fxp1, etc... Of course this would depend on finding the busses in the > right order, but... This would be nice. But, if bus or device ordering changes, you'd still be up the same creek. You'd have to wire things down in a card-specific way and not a bus/slot-specific way. > Unfortunately, I'm, uh, somewhat unexperience in this (and most of the > rest) of the code and when I looked at it, all I got was a headache. How > hard would it be to either provide a consistent mapping or to allow the > hard-wiring of devices to drivers? -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: distfiles no longer on 4.0 CDs
On Wed, 19 Apr 2000, Jordan K. Hubbard wrote: > That would not be a simple solution. There are more packaging > problems with this than you've probably ever dealt with since we deal > with CD sets in terms of tens-of-thousands quantities. > > I will continue to explore going to a 6 CD set, but that also means > more work for me on every release so I'm in no particular hurry. :) How about using 80-minute/700MB discs? It would only let you squeeze in another 50MB/disc, but that would mean an extra 200MB for the 4-CD set. Apparently this is what Microsoft and many others have been doing for a while now. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
