Re: smbfs-1.3.0 released
On Fri, 27 Oct 2000, Shawn Halpenny wrote: > Speaking of smbfs, has anyone else run into an odd bug using it in > 4.1.1-STABLE? Occasionally, if I run 'df' or try to access the > directories (e.g. using 'ls') for an smbfs mount after a period > of time during which there were no accesses across that mount > point (e.g. mount, don't touch it for an hour, then try 'df'), my > machine will reboot after a few seconds. No panic message or > anything--it's just like I pressed the reset button. I've not had it panic on me under those situations, but it does do weird things. I think I'd either get an empty directory listing, or it would say "path too long" or something like that and any relative path stuff like "cd .." wouldn't work. I'd have to give a full path to get where I wanted to go, even if it was the _same_ directory. I've also had cases where I was drilling down through the directories in the Save File dialog in Navigator and I would get incomplete directory listings. Also, it seems, if I try to save a file that way, the file ends up corrupted. If I save it to a local filesystem and then move it over manually, its fine. Other than those small annoyances, it seems to work great. Oh yeah, I've noticed one more thing. When you're at the root of a mount, you can cd into a directory using any case, but if you get the case wrong, you don't get a listing. Here's an example: root@tech43 [/smb/rsisfs1/d]# ls ADMINNOTIFY/REB98/ SECURITY/ SHARES/ tmpacls.bat* CPQIS1/ RECYCLER/ SETACLS.BAT*TEMP/ root@tech43 [/smb/rsisfs1/d]# cd reb98 root@tech43 [/smb/rsisfs1/d/reb98]# ls root@tech43 [/smb/rsisfs1/d/reb98]# cd ../REB98 root@tech43 [/smb/rsisfs1/d/REB98]# ls ARCHIVE/PACKAGES/ AUTOEXEC.BAT* PCRDIST/ BATCH/ REBMIR.LOG* ... and so on ... root@tech43 [/smb/rsisfs1/d/REB98]# cd packages packages: No such file or directory. root@tech43 [/smb/rsisfs1/d/REB98]# cd PACKAGES root@tech43 [/smb/rsisfs1/d/REB98/PACKAGES]# So... the case-insensitivity only happens at the root of the mount. Should it happen everywhere? It'd be nice if it did. :-) -- 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
Re: USB-to-SCSI converter
On Thu, 9 Nov 2000, Nick Hibma wrote: > This is not a problem as the thing works although it displays the > message. Because it does not support the call it gives an > indication that multi LUN devices are not supported. > > I have one of these cables and managed to newfs a 4Gb SCSI drive. > > Was anything connected to the cable when you connected it? I'm looking for a USB to SCSI converter myself... are there any that are a little more well-behaved and work great with FreeBSD and Windows (preferably one that Win98+ will see without having to carry around a driver disk)? I doubt I'll ever attach multi-lun devices to it either, but I don't like my options limited. :-) -- 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
Re: USB-to-SCSI converter
On Fri, 10 Nov 2000, Nick Hibma wrote: > This makes sense as the adapter is not a ful controller, just a > cheapo interface. > > You cannot select the SCSI id from the USB driver. Hmm.. Since I was looking for a "true" USB-SCSI controller, obviously this thing won't work. If it only works with devices set to ID 0, it will never work with a SCSI ZIP drive which only has settings for ID 5 or 6 (which is one thing I would use it with). Do the Shuttle-based USB-SCSI adapters have the same limitation? -- 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
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
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch oflicence Jihad crap
On Wed, 27 Dec 2000, Jeremiah Gowdy wrote: > > The amount of free Windows software is much less than what is > > available for Unix. > > I almost choked to death on my Submarina Sandwich when I read > this. I think you need to take a step back and think a bit on > this one. Do you really think the 4000-5000 ports in the ports > tree and the other misc free applications on the net outnumber the > hundreds of thousands of free Windows applications ? Even if you > don't count Shareware, which you really should, the number of free > Windows applications outnumbers the number of free Unix > applications 10 to 1. Now, the power, importance, usefulness, etc > of the Unix apps may be superior, but the "amount" or number of > free Windows applications is certainly not "much less" than what > is available for Unix. It's much much more. Giving Windows a :( > for Free Applications is absolutely unbelievable. Oh, and if > you're going to include all of the Linux binary compatible > applications as "free software for FreeBSD", then you would have > to include in Windows 2000's count all of the DOS binaries it is > compatible with, which far far outnumbers any amount of software > written for any operating system ever. The amount of freeware > produced between MSDOS 3 and MSDOS 6 is uncountable, and much of > it is compatible with Windows 2000. Uuuuh, I'm gonna have to agree with Murray that there is a complete dearth of free software for Windows. Go search shareware.com, or Tucows, or any of the other Windows-centric software sites, and just TRY to find most of the same tools or applications you take for granted on your Unix box. I do all the time, and wished to hell I was managing thousands of BSD boxes instead of Windows. The free software either doesn't exist, is of very poor quality, or you have to pay for it. While "free as in beer" software for Windows is fairly prevalent, GOOD free software is quite rare, and open-sourced software for Windows is very rare indeed. The Windows-programmer mindset that is still very prevalent, even in this "open-source" day and age, is "I'll make this proprietary piece of software, of which there are forty different other pieces of software almost like it, not release any code, and you're gonna pay me for it one way or another if you want to use 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
Re: CVSup7.FreeBSD.org is back in service
On Fri, 2 Feb 2001, John Polstra wrote: > In article <[EMAIL PROTECTED]>, > Julian Elischer <[EMAIL PROTECTED]> wrote: > > > > I have the folowing suggestion for CVSup.. > > the ability to specify several servers. > > Cvsup can have a quick exchange with each to inquire about load and check the > > latency and bandwidth > > and the last time updated, and choose the best > > Since you control both ends this is possible.. > > This is a frequently requested feature, but I've always been reluctant > to provide it. Human nature being what it is, I'm afraid soon > everybody would have 15 servers listed in their supfiles. So 15 > servers would get hit on each update instead of just one. It is > true that the load query wouldn't hit the servers nearly as hard as > an actual update. But it would require forking a process at least. [...] Finding the fastest server isn't always as important as finding one that works. I had my mirror pointed at cvsup7 (or maybe it was cvsup6) when it went away for a while, and I never knew the updates were failing until after several cvsups from my mirror I noticed nothing was changing, which is very unusual. :-) A nice feature would be to add multiple cvsup servers to use as fallbacks with some way of knowing if the server you've just fallen back to has a later copy of the tree than you do. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
On Thu, 8 Feb 2001, Bill Paul wrote: > http://www.freebsd.org/~wpaul/FEC/4.x/fec.tar.gz > http://www.freebsd.org/~wpaul/FEC/5.x/fec.tar.gz > > This is a call for testers for a netgraph module that can be used > to aggregate 2 or 4 ethernet interfaces into a single interface. > Basically, it lets you do things like the following: [snip] > The fec module will work with *any* combination of interfaces, not > just multiport ethernet cards, however the port failover mechanism > will not work unless the interface supports ifmedia and is able to > report the link status. Cards that use the fxp, de, xl, tl, rl, > sis, dc, wb, ste, sf, vr, ti and sk drivers should work. Yes, that > means you can aggregate RealTek cards and gigabit ethernet cards > together. Awesome! I've been using channel bonding/port-failover on my NT servers for at least a couple of years now. One thing, though, wouldn't the plural of 'fec' be 'feces'? :-) > The channel bonding is done using the Cisco fast etherchannel > mechanism. The default hashing mechanism uses the MAC address, > however you can select IP address hashing as well. IPv4 and IPv6 > address *should* work, though I must admit I've been using IPv4 > until now. If someone actually has a Cisco switch that implements > fast ethetchannel, I'd be interested to know if it works with this > module. At the moment, my test environment consist of two machines > with multiport ethernet cards wired up using four crossover > cables. Apparently there is another way to do channel bonding with switches that don't support Cisco's EtherChannel, since I'm doing it with 3COM's (piece of *hit) SuperStackII switches and I don't have EtherChannel support enabled in Compaq's NT drivers for their Intel NICs. I will try this out on -stable at work, but the only switches I have handy that support EtherChannel are some HP ProCurve 4000Ms. Is there any chance that the EtherChannel method would work on something like a 3COM SuperStackII 3300, which doesn't claim to support EtherChannel? > Each link is checked once every second to see if the link is still > up. An attempt to send a packet over a dead link will cause the > packet to be shifted over to the next link in the bundle. Apparently Compaq's NT driver (actually most likely Intel's, slightly modified by Compaq) sends out a heartbeat packet from each interface if there has been no incoming traffic on the interfaces within the heartbeat period. I haven't sniffed the heartbeat packet yet to figure out if it is simply sent to a broadcast address (which it appears to be, since the switch appears to forward it to all ports), or if it is sending it from one interface addressed to another interface, or even to the same interface. [snip] > The fec0 pseudo-interface will inherit the MAC address of the first > real interface to be added to the bundle, and that same MAC address > will be propagated to all subsequent interfaces that are added. [snip] Hmmm... The non-EtherChannel method apparently uses a different MAC for each interface, since when I have looked at the forwarding tables of my switches where I have two bonded channels from a server, each port shows a different MAC address. Any idea how that would work? It would be really cool if you could choose either the EtherChannel method or some other non-EtherChannel method that will work with other switches, if we can figure out how it works. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
On Fri, 9 Feb 2001, Dan Nelson wrote: > In the last episode (Feb 08), Chris Dillon said: > > > The channel bonding is done using the Cisco fast etherchannel > > > mechanism. The default hashing mechanism uses the MAC address, > > > however you can select IP address hashing as well. IPv4 and IPv6 > > > address *should* work, though I must admit I've been using IPv4 > > > until now. If someone actually has a Cisco switch that implements > > > fast ethetchannel, I'd be interested to know if it works with this > > > module. At the moment, my test environment consist of two machines > > > with multiport ethernet cards wired up using four crossover cables. > > > > Apparently there is another way to do channel bonding with switches > > that don't support Cisco's EtherChannel, since I'm doing it with > > 3COM's (piece of *hit) SuperStackII switches and I don't have > > EtherChannel support enabled in Compaq's NT drivers for their Intel > > NICs. > > I've just finished scouring Cisco's documentation, and it doesn't > look like FEC is anything beyond plain old trunking (with the > option of autoconfiguration on some hardware). As long as you > configure the appropriate ports on the switch on the other end as > "SA-Trunk", or "Trunk", you should be okay. Cool, if thats all it will take, I'll give it a try. But, whatever method Compaq/Intel is using doesn't require me to set up the ports on the switch as being part of a trunk. It "just works". And IIRC, when I actually tried to set the ports on the 3COM switch up as trunk ports, it didn't work right. Maybe 3COM is doing something entirely different. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
On Fri, 9 Feb 2001, Alex Pilosov wrote: > On Fri, 9 Feb 2001, Chris Dillon wrote: > > > Cool, if thats all it will take, I'll give it a try. But, whatever > > method Compaq/Intel is using doesn't require me to set up the ports on > > the switch as being part of a trunk. It "just works". And IIRC, when > > Its not real trunking. Your incoming traffic will still come on a > single link, only outbound traffic will be shared. (Or at least > that's how I think compaq stuff will work). Yes, I think that is how it works. I'd guess that this doesn't matter in most cases since most servers are transmitting much more data than they are receiving. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
On Mon, 5 Mar 2001, E.B. Dreger wrote: > > Date: Sun, 04 Mar 2001 19:39:09 -0600 > > From: David A. Gobeille <[EMAIL PROTECTED]> > > > > It would also be interesting to see the numbers for an Athlon/PIII > > system with DDR, if anyone has such a machine. > > Personally, I'd be [more] interested in a ServerWorks III HE core chipset > with four-way interleaved SDRAM. :-) I've got a ServerWorks III HE-SL system with 512MB of two-way interleaved PC133 SDRAM and dual PIII-800's. Is that close enough? :-) Here is my "memory bandwidth test", much much simpler and less scientific than Matt's: dd if=/dev/zero of=/dev/null bs=10m count=1000 1000+0 records in 1000+0 records out 1048576 bytes transferred in 23.716504 secs (442129245 bytes/sec) I just did a recent 4.2-STABLE 'make -j 4 buildworld' on that system in just over 34 minutes. Here's the time output: 1980.707u 768.223s 34:20.89 133.3% 1297+1456k 39517+6202io 1661pf+0w > If one _truly_ needs the bandwidth of Rambus (which, IIRC, is > higher real-world latency than SDRAM), then how about having the > bus bandwidth to back it up? The higher real-world latency of RDRAM over SDRAM is what makes the benefits of its higher bandwidth so questionable. PC2100 DDR-SDRAM -- which has higher latencies than regular SDRAM but still lower than RDRAM -- should have it beat soundly, though we'll have to wait for some systems that are actually designed to take advantage of it to say for sure. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing support in FreeBSD for large file sizes?
On Mon, 5 Mar 2001, Matthew Jacob wrote: > Very annoying. And Maxtor also missed that Networker is available > for FreeBSD as well. And Veritas NetBackup BusinesServer/DataCenter. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Machines are getting too damn fast
On Mon, 5 Mar 2001, Matt Dillon wrote: > :On Mon, 5 Mar 2001, E.B. Dreger wrote: > : > :I've got a ServerWorks III HE-SL system with 512MB of two-way > :interleaved PC133 SDRAM and dual PIII-800's. Is that close enough? > ::-) > : > :Here is my "memory bandwidth test", much much simpler and less > :scientific than Matt's: > : > :dd if=/dev/zero of=/dev/null bs=10m count=1000 > :1000+0 records in > :1000+0 records out > :1048576 bytes transferred in 23.716504 secs (442129245 bytes/sec) > : > :I just did a recent 4.2-STABLE 'make -j 4 buildworld' on that system > :in just over 34 minutes. Here's the time output: > :1980.707u 768.223s 34:20.89 133.3% 1297+1456k 39517+6202io 1661pf+0w > > That is quite impressive for SDRAM, though I'm not exactly sure what's > being measured due to the way /dev/zero and /dev/null operate. On > my system the above dd test returns around 883MB/sec so I would guess > that it is only doing a read-swipe on the memory. I figured if /dev/null and /dev/zero had relatively little memory impact, which I figure is the case, it would matter more how dd does its blocking. If you reduce the blocksize to something that will fit in your L2 caches, you'll see a very significant increase in throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its overclocked) here on my desk with 256KB L2 cache: dd if=/dev/zero of=/dev/null bs=10m count=200 200+0 records in 200+0 records out 2097152000 bytes transferred in 10.032157 secs (209042982 bytes/sec) dd if=/dev/zero of=/dev/null bs=512k count=4000 4000+0 records in 4000+0 records out 2097152000 bytes transferred in 8.229456 secs (254834825 bytes/sec) dd if=/dev/zero of=/dev/null bs=128k count=16000 16000+0 records in 16000+0 records out 2097152000 bytes transferred in 1.204001 secs (1741819224 bytes/sec) Now THAT is a significant difference. :-) > (sony 1.3G / RIMM) > apollo:/home/dillon> dd if=/dev/zero of=/dev/null bs=10m count=1000 > 1000+0 records in > 1000+0 records out > 1048576 bytes transferred in 11.867550 secs (883565697 bytes/sec) Very impressive. Looks about right given the theoretical maximum bandwidth of your memory system. >From what I've been gathering, that dd-test shows roughly 1/4 of the total theoretical memory bandwidth (two reads and two writes happening?), minus any chipset deficiencies when it comes to memory transfers. For example, this PIII-850 on a BX board is actually an overclocked 700MHz 100MHz FSB PIII. So, it is using a 116MHz FSB and the SDRAM is running at that speed as well. The theoretical maximum bandwidth of this should be 8(bytes-per-clock)*116(MHz)=928MB/sec. I'm seeing about 210MB/sec on the dd-test, so thats pretty close to 1/4. In your case, you are using PC800 RDRAM on a Pentium-4 system on an i850 board, which IIRC uses a dual-channel RDRAM setup, theoretically doubling the bandwidth that you could get with only one channel. Since you're using dual RDRAM channels of PC800 RDRAM, that would be 4(bytes-per-clock)*800(MHz)=3200MB/sec. Again, the dd-test is pretty close to 1/4 the total theoretical bandwidth (actually a little over), since you achieved about 883MB/sec. In an HE-SL system I have here, it uses dual-interleaved PC133 SDRAM. That would be 16(bytes-per-clock)*133(MHz)=2128MB/sec. The dd-test is a little off the mark of 1/4 the theoretical maximum bandwidth at 442MB/sec, but this thing is the only system I've seen the dd-test on so far that hasn't used an Intel chipset. The Intel chipsets have shown in other benchmarks to be more efficient than anybody else's chipsets (VIA, AMD, RCC, etc) at doing the memory thing, so that makes sense. I think I'm on to something here with this 'cheap' dd-test. :-) A PC2100 DDR-SDRAM system will have a theoretical bandwidth of 2100MB/sec (duh), so a dd-test should come out to around 525MB/sec. I'm guessing it will actually be a bit less since the AMD and especially VIA chipsets aren't going to be anywhere near as efficient as the Intels have been. I'm guessing 95% efficiency for the AMD, so about 500MB/sec from the dd-test. 85% efficient for the VIA, so around 450MB/sec. Anyone care to test that on one or both of the new AMD-chipset and VIA-chipset DDR systems and see how close it comes? :-) > The only thing I don't like about this baby is the IBM IDE hard drive's > write performance. I only get 10-12 MBytes/sec. Read performance is > incredible, though... I get 37MB/sec dd'ing from /dev/ad0s1a to > /dev/null. > > ad0: 58644MB [119150/16/63] at ata0-master UDMA100 That is a 75GXP series, which is supposed to be one of the fastest, if not the fastest, IDE drive on the market right now. Hmm. -- Chris Dillon - [EMAIL PROTECTED] - [EM
Re: Machines are getting too damn fast
On Mon, 5 Mar 2001, Matt Dillon wrote: > :throughput. For example, on the PIII-850 (116MHz FSB and SDRAM, its > :overclocked) here on my desk with 256KB L2 cache: > : > :dd if=/dev/zero of=/dev/null bs=512k count=4000 > :4000+0 records in > :4000+0 records out > :2097152000 bytes transferred in 8.229456 secs (254834825 bytes/sec) > : > :dd if=/dev/zero of=/dev/null bs=128k count=16000 > :16000+0 records in > :16000+0 records out > :2097152000 bytes transferred in 1.204001 secs (1741819224 bytes/sec) > : > :Now THAT is a significant difference. :-) > > Interesting. I get very different results with the 1.3 GHz P4. The > best I seem to get is 1.4 GBytes/sec. I'm not sure what the L2 cache > is on the box, but it's definitely a consumer model. > > dd if=/dev/zero of=/dev/null bs=512k count=4000 > 2097152000 bytes transferred in 2.363903 secs (887156520 bytes/sec) > > dd if=/dev/zero of=/dev/null bs=128k count=16000 > 2097152000 bytes transferred in 1.471046 secs (1425619621 bytes/sec) > > If I use lower block sizes the syscall overhead blows up the > performance (it gets lower rather then higher). So I figure I don't > have as much L2 as on your system. IIRC, Intel is using a very different caching method on the P4 from what we are used to on just about every other x86 processor we've seen. Well, I can't remember if the data cache has changed much, but the instruction cache has. I doubt the difference in instruction cache behaviour would make a difference here though. Hmm. I wonder if it makes any difference that I'm using -march=pentium -mcpu=pentium for my CFLAGS? Actually, the kernel I tested on might even be using -march/-mcpu=pentiumpro, since I only recently changed it to =pentium to allow me to do buildworlds for another Pentium-class machine. I did wonder the same thing a while back and did the same test with and without the optimizations, and with pentiumpro opts the big block size transfer rate went _down_ a little bit, which was odd. I didn't compare with L2-cache-friendly blocks, though. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ecc kld for FreeBSD 4.2
On Mon, 12 Mar 2001, Chris Sears wrote:
>
> Linux has some support for ECC error detection:
>
> http://www.anime.net/~goemon/linux-ecc/
>
> I've ported ECC 0.12 to a FreeBSD kld and it seems to work.
>
> A couple of minor changes:
>
>commented out probe_450gx because the compiler was
>giving some plausible warnings
>
>check if ecc_mode == ECC_NONE before installing the timer
>
> I've attached it and would welcome any comments. I've also
> posted it back to the Linux ECC people.
Excellent!! I've just compiled it and loaded it on my 4.2-STABLE
system with a 440BX-based board. I even have an enhancement already,
which is pretty much just a cut-n-paste from the Linux bits with a
little bit of style enhancement, though you'll want to change it to
your liking, and since I'm not an avid C programmer, make sure I've
done the right stuff... (it DOES work, at least):
--- ecc.c.orig Tue Mar 13 15:17:57 2001
+++ ecc.c Tue Mar 13 16:31:02 2001
@@ -1040,6 +1040,26 @@
int type,
void* data)
{
+char *ecc[] = {
+ "None",
+ "Reserved",
+ "Parity checking",
+ "ECC detection",
+ "ECC detection and correction",
+ "ECC with hardware scrubber"
+ };
+char *dram[] = {
+ "Empty",
+ "Reserved",
+ "FPM",
+ "EDO",
+ "BEDO",
+ "SDR",
+ "DDR",
+ "RDR"
+ };
+ unsigned long mem_end = 0;
+ unsigned long last_mem = 0;
static int attached = 0;
int loop;
@@ -1068,6 +1088,25 @@
if (cs.ecc_mode == ECC_NONE) {
printf("ECC: no ECC memory\n");
return -ENODEV;
+ } else {
+ printf("ECC: Chipset ECC capability - %s\n",
+ ecc[cs.ecc_cap]);
+ printf("ECC: Current ECC mode - %s\n",
+ ecc[cs.ecc_mode]);
+ printf("ECC:\tBank\tSize\tType\tECC\tSBE\tMBE\n");
+ for (loop = 0; loop < 8; loop++) {
+ last_mem = bank[loop].endaddr;
+ if (last_mem > mem_end) {
+ printf("ECC:\t%d\t", loop);
+ printf("%dM\t", (int)(last_mem - mem_end) /
+1048576);
+ printf("%s\t", dram[bank[loop].mtype]);
+ printf("%s\t", bank[loop].eccmode ? "Y" : "N");
+ printf("%d\t", bank[loop].sbecount);
+ printf("%d\n", bank[loop].mbecount);
+ mem_end = last_mem;
+ }
+ }
+ printf("ECC: Total\t%dM\n", (int)mem_end / 1048576);
}
attached = 1;
break;
I also have something that I can hopefully just plug the bits into to
get this working for the ServerWorks III chipset, as well, assuming I
can find the right info about it...
-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED]
FreeBSD: The fastest and most stable server OS on the planet.
For IA32 and Alpha architectures. IA64, PPC, and ARM under development.
http://www.freebsd.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: ecc kld for FreeBSD 4.2
On Mon, 12 Mar 2001, Chris Sears wrote: > I've ported ECC 0.12 to a FreeBSD kld and it seems to work. Oh yeah, I don't see a license on this file. If the author has no problems with putting a BSD license on this, this would be great to stick in RELENG_4 and HEAD for the many of us who actually use ECC systems. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ecc kld for FreeBSD 4.2
On Tue, 13 Mar 2001, Chris Sears wrote: > THANKS! and compliments on your name. It was a quick and simple > port to see if people were interested. I've sent it to the > author/maintainer Dan Hollis but I haven't gotten a response yet. > He has an email list on Yahoo/Groups and there is occasional > traffic so it isn't dead code. I'm sure there would be much interest, especially since FreeBSD is run on many systems with ECC memory subsystems. I, for one, don't build a server without ECC memory and a chipset that does auto-correction/scrubbing. It would be taboo. Even my workstations have it. :-) > Yes, I did notice that there was no licensing. I will broach that > with him. I can live with GPL since I see this as being a KLD > which can be installed from source. But I prefer BSD. Since not everybody would want to use a module, or even could use a module, a BSD license would be ideal so that it could be compiled directly into the kernel. It is entirely up to the author what he wants to use, of course. > DEV_MODULE vs DRIVER_MODULE. It is true that DEV_MODULE is much > less common but it is minimally sufficient. If it were a > DRIVER_MODULE, then it would just be allocating a bunch of > structures and entry points and noop'ing them out. But perhaps > someone else could lend an opinion. Looking at the differences, DEV_MODULE did look quite a bit easier to use. :-) > Thanks for the 440BX patch, I'll add it. As far as the > ServerWorks III chipset, the necessary documentation has *not* > been available. I think they are a small company and a little > paranoid WRT intellectual property. If you have it, or if you can > get it, this would be great. It wasn't really a 440BX-related patch, just some pretty-print information when the module was loaded, some of which is probably irrelevant and could be removed (such as the SBE/MBE stuff). Just saying that the ECC module was loaded was a little bit too light on the information side. :-) On a similar note, how can we go about getting similar run-time information out of this, such as the current count of SBEs and MBEs? Some sysctls perhaps? The current code uses procfs under Linux, but that seems ugly to me. > Basically, I would like to break the file into Linux, BSD and ecc > sections. This would simplify things for the author who has > expressed interest in a kernel patch as well as a module. The > reason for kernel was that module support can be config'd out on > Linux. I talked to Daniel O'Connor on IRC, and he mentioned he would like to clean it up a bit. Splitting it into OS-specific and OS-independant parts would be a good idea, I think. > I'm not sure how kld's are distributed as there don't seem to be > any in the ports collection. And I wouldn't mind cleaning it up a > bit. Actually, I can think of at least two -- ports/emulators/rtc, depended on by the ports/emulators/vmware2 port, which has yet another kernel module in it. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Concept check: iothreads addition to pthreads for MYSQL+FreeBSD.
On Mon, 10 Jan 2000, Scott Hess wrote: > 4) Is there anyone willing to commit to testing my modified pthreads > library against MYSQL? [I'll be stress testing it quite heavily, of > course. It would probably also be testable against Squid with async I/O > and multithreaded Apache 2.0.] I'm willing to test this on Squid 2.2STABLE5 with async I/O compiled in, assuming I can get it to compile. Currently when I try to compile the Squid port with --enable-async-io, it complains thusly: cc -O -pipe -D_REENTRANT -I. -I../include -I../include -c send-announce.c aiops.o(.text+0x80): undefined reference to `pthread_cond_init' aiops.o(.text+0xaf): undefined reference to `pthread_create' aiops.o: In function `aio_thread_loop': aiops.o(.text+0x130): undefined reference to `pthread_sigmask' aiops.o(.text+0x139): undefined reference to `pthread_mutex_lock' aiops.o(.text+0x169): undefined reference to `pthread_cond_timedwait' aiops.o: In function `aio_process_request_queue': aiops.o(.text+0x64e): undefined reference to `pthread_cond_signal' *** Error code 1 Stop. I'm running a very recent 3.4-STABLE. I'm assuming the work you do will apply to -STABLE since you're running a production server. :-) This box only gets an average load most of the time, but will see an occasional high peak, so it should be a fair test subject. -- 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-hackers" in the body of the message
Re: looking for victims, err, uh, 'volunteers'
On Fri, 14 Jan 2000, Matthew Jacob wrote: > I've just committed into -current a bare-bones SES/SAF-TE driver that will > be fleshed out somewhat over the next couple of days, but will remain a > bare bones driver. It's a stub right now (just matches && attaches), but > the rest of it will show up tomorrow. Yay! > There will be a simple ioctl API to get to it, but I won't be putting > any management daemons into the source tree- there has been no clear > consensus on how to manage a lot of this, so any tools to extract info at > best will be in /usr/contrib or /usr/ports. > > That said... if anyone out there has (they believe) any SES or SAF-TE (or > even Sun RSM trays that have the Unisys SEN card in them) and wants > perhaps act as a guinea pig, I'd appreciate hearing about it. The tools > and usage is pretty lightweight and I just pretty much need to > crosscheck/port some tools I did on Solaris for FreeBSD. I've got a Compaq Proliant 3000 with three drives in a hot-plug chassis that I was told by someone else a while back (you?) speak SAF-TE. Unfortunately, I'm running -STABLE on that box. If this would happen to work with -STABLE, I just _happen_ to have a disk that is giving me fits (medium errors resulting in unrecoverable read errors) and am about to go in tomorrow to swap it with another disk. Since the disk wasn't really doing anything too terribly important (holding one-third of my Squid cache, /usr/obj, and a copy of the FreeBSD CVS repository), I can hold off replacing it for a while if it needs to be used as a test subject. -- 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-hackers" in the body of the message
Re: looking for victims, err, uh, 'volunteers'
On Sun, 16 Jan 2000, Matthew Jacob wrote: > > > > > I've got a Compaq Proliant 3000 with three drives in a hot-plug > > chassis that I was told by someone else a while back (you?) speak > > SAF-TE. Unfortunately, I'm running -STABLE on that box. If this > > would happen to work with -STABLE, > > If all goes well, I'll do a MFC next week or so. OK. I'll go ahead and replace the disk for now. > > I just _happen_ to have a disk that > > is giving me fits (medium errors resulting in unrecoverable read > > errors) and am about to go in tomorrow to swap it with another disk. > > Since the disk wasn't really doing anything too terribly important > > (holding one-third of my Squid cache, /usr/obj, and a copy of the > > FreeBSD CVS repository), I can hold off replacing it for a while if it > > needs to be used as a test subject. > > > This would not likely be seen as an Environmental Services issue- this is > already being reported via the SCSI Direct Access (da) driver. In fact, one of > the big lacks of SES/SAF-TE is the difficulty in correlating errors from > entities within a box and errors reported by the box. > > SES/SAF-TE is more for disk boxes, etc.. For example, on quarm I have a Sun > A5000 on a fibre channel loop: Hmm... I guess I was confusing this with the S.M.A.R.T. stuff that is supposed to give you a kind of pre-emptive warning that bad things are going to happen (or have happened, rather... i.e. the drive starts reallocating a bunch of blocks or senses some other kind of internal problem). Will what you've done at least allow the nifty "I'm OK" LED to light up on the hot-swap disk tray like it does on the NT boxen? *duck* :-) On a similar note, I guess, how exactly _would_ you query a drive about its SMART status in FreeBSD? It would be neat to have the status LEDs on the drive trays reflect the health of the drive. If I read your description of the SAF-TE/SES stuff right, that is what would be used to twiddle the LED off/on. -- 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-hackers" in the body of the message
Re: Bad memory suspected
On Tue, 1 Feb 2000, Willem Jan Withagen wrote: > I too agree with Doug. It is what causes me to ask this question. > ;-) make -j 4 buildworld keeps me getting crashes. Even during > making the temp-tools. > > Now I've already replaced the memory once: 4*16M out, in 4*32M, > but the crashingis still there. I've even set the timing to it's > lowest, but still no go. > > I could go out an buy more new parts, but this is one of the cases > to get to know FreeBSD again a little better. Memory testing > skills are a leftover from a previous life. Heck, i've even help > design a state-machine to test embeded RAM on VLSI ;-) The last time I had a problem like this, it was because I put a P54C (Pentium-MMX) into a board only designed for the P53C (a.k.a standard Pentium), so the core and I/O voltages were not quite correct. I knew this could be a problem, but I tried it anyway, and it worked (mostly). No amount of memory replacement or tweaking fixed the occasional problem, even though that is exactly what the problem looked like. It worked fine 99.9% of the time, but at least once a day it would crash hard. When I popped in a regular old Pentium processor that I knew the board could support, it worked flawlessly for weeks. When I put the Pentium-MMX into a newer board that supported it, it worked flawlessly as well. So, other than memory, you should check out both your motherboard and CPU. Try underclocking the CPU and see if that fixes your problems. -- 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-hackers" in the body of the message
Re: Bad memory suspected
On Tue, 1 Feb 2000, Matthew D. Fuller wrote: > On Tue, Feb 01, 2000 at 05:01:55PM -0600, a little birdie told me > that Chris Dillon remarked > > > > The last time I had a problem like this, it was because I put a P54C > > (Pentium-MMX) into a board only designed for the P53C (a.k.a standard > > ITYM P55C on a P54C board. Errr, yes. Computers aren't the only things that suffer from off-by-one problems. ;-> -- 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-hackers" in the body of the message
PROBLEM FOUND (sort of): Re: lpr: order of print requests
On Tue, 2 May 2000, Konrad Heuer wrote: > > On Tue, 2 May 2000, Lorenzo Iania wrote: > > > Warren Losh wrote: > > > > > LPR queues up the reuqests and prints them in order smallest to > > > largest to reduce the average wait time for a job at the expense of > > > having a larger standard deviation in the wait times for jobs. Maybe > > > this is what you are running into. I don't know if there's a way to > > > disable this behavior or not. At least that's what I recall lpd doing > > > years ago when I ran a unix lab in school. I didn't go check the code > > > to see if it still did that or not. > > > > > > Warner > > > > > > > I think you're right, because the process that generates the requests is > > only one. It consecutively opens pipes to lpr and then closes them. In > > effect it builds invoices from delivery documents and the printed numbers of > > invoices is effectively out of order, while the requests are ordered by > > number of invoice. Each pipe is opened and closed: so the processes are not > > concurrent: one begins after the other has finished. > > So, is there a way to disable this strange behavior? > > Hmm, I've never seen such a strange behaviour. Lpd should do FIFO. Could > you give some more infos about your environment (os release, input filter > program, printer type)? I had the same problem when I used Samba and a FreeBSD box as an intermediary print queue to a networked laser printer for some Win95 boxes. Needless to say, the secretaries didn't like the fact that all of the checks they printed were out of order on numbered check stock. :-( This is definately a bug, probably in the queue sort routine in usr.sbin/lpr/common_source/common.c. I'm no good at C programming, or I'd take a shot at finding the exact culprit and fixing it myself. I'm on 4.0-STABLE, and here is what I can produce: # lpq -a # for foo in 1 2 3 4 5 6 7 8 9 10; do echo "$foo" | lpr -Praw; done # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1stroot 41 (standard input) 3 bytes 2ndroot 33 (standard input) 2 bytes 3rdroot 34 (standard input) 2 bytes 4throot 35 (standard input) 2 bytes 5throot 36 (standard input) 2 bytes 6throot 37 (standard input) 2 bytes 7throot 38 (standard input) 2 bytes 8throot 39 (standard input) 2 bytes 9throot 40 (standard input) 2 bytes 10th root 32 (standard input) 2 bytes Notice the rank and job numbers, and that jobs 32 and 41 are swapped. Looking at the raw job data in the spool directory verifies that each sequential job is being placed into the queue with a correct sequential job number. Investigating further, this happens: Place just six jobs in the queue, and things are peachy: # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1stroot 79 (standard input) 2 bytes 2ndroot 80 (standard input) 2 bytes 3rdroot 81 (standard input) 2 bytes 4throot 82 (standard input) 2 bytes 5throot 83 (standard input) 2 bytes 6throot 84 (standard input) 2 bytes Add a seventh job and the odd sorting behaviour happens: # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1stroot 82 (standard input) 2 bytes 2ndroot 80 (standard input) 2 bytes 3rdroot 81 (standard input) 2 bytes 4throot 79 (standard input) 2 bytes 5throot 83 (standard input) 2 bytes 6throot 84 (standard input) 2 bytes 7throot 85 (standard input) 2 bytes The print queue is sorted by qsort(), so this wouldn't have anything to do with the magic number "7" I see in lib/libc/stdlib/qsort.c, would it? (ignore me... its probably just a coincidence) :-) -- 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-hackers" in the body of the message
Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests
On Tue, 2 May 2000, Dan Nelson wrote: > In the last episode (May 02), Chris Dillon said: > > On Tue, 2 May 2000, Konrad Heuer wrote: > > > Hmm, I've never seen such a strange behaviour. Lpd should do FIFO. > > > Could you give some more infos about your environment (os release, > > > input filter program, printer type)? > > Aha. Yes, it _does_ do FIFO, but if you look at the source, the queue > sorting routine simply sorts on stat(mtime) of the queue file, so jobs > submitted in the same second will sort randomly. A quick fix would be > to sleep for 1 second between "lpr" calls. That isn't the problem. You can sleep as much as you want between submitting the print jobs and the job order still gets munged. Even a job that at one time had #1 rank gets inverted and ends up with the lowest rank. I even modified common.c (a shot in the dark, I had no idea what I was doing, really) to check for modtime with st_mtimespec.tv_nsec for nsec modtime resolution, and that didn't change the behaviour any. It appears that qsort() is the culprit. In fact, here is an excerpt from the manpage: The functions qsort() and heapsort() are not stable, that is, if two mem- bers compare as equal, their order in the sorted array is undefined. The function mergesort() is stable. You would think that with nsec modtime resolution, the chance of two jobs having equal sort criteria is slim to none, so most likely I didn't do the modtime change correctly. I wonder if we can work mergesort() in there somehow. I also notice that the job numbers assigned to the jobs are sequential, so maybe that can be a sort criteria as well. I'm just being a detective, but I'm not a C programmer, so don't look at me. :-) -- 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-hackers" in the body of the message
Re: PROBLEM FOUND (sort of): Re: lpr: order of print requests
On Wed, 3 May 2000, Garance A Drosihn wrote: > With the update I made, the sort will be stable because the two > filenames will not be equal. Please try the update at: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=18361 > [PATCH] Fix for queue-ordering problem in lpr/lpd/lpq > > or pick up the update from: > ftp://freefour.acs.rpi.edu/pub/bsdlpr/lpr_qfix.diff This is excellent. I beat on it with my test-case and it works fine. Could someone please commit this to 5-CURRENT, 4-STABLE and even 3-STABLE? I imagine even 2.2-STABLE users wouldn't mind. -- 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-hackers" in the body of the message
Re: changed pci bus probe order from 3.2 to 4.0 -- ideas?
On Thu, 1 Jun 2000, Kenneth D. Merry wrote: > On Thu, Jun 01, 2000 at 11:19:29 -0600, Fred Clift wrote: > > > > > > i suppose the only place where you use the actual card names > > > is the firewall config and rc.conf -- can't you just make these > > > scripts fetch the ethernet address of the card(s), set a shell > > > variable with the name of the good card, and go ahead with that ? > > > > Yeah I'm about to the point of doing this for lack of other options. > > Thanks for the sample code -- I'm sure it'll come in handy if I can solve > > this any other way. > > > > The best fix would be to find a way to hard-wire which card is which in > > the kernel config (ie fxp0 is always on pci0...) but I dont know if you > > can do that kind of thing with pci devices. > > The problem is that when the new-bus code was introduced, the probe order > was changed from a bus-by-bus probe (breadth first?) to a depth-first > probe. > > i.e. as soon as another PCI bus is found (e.g. on a bridge chip) it is > probed, rather than deferring the probe of the new bus until the probe of > the current bus has been completed. > > I think Doug Rabson had plans to fix the probe order, but it never > happened. > > There is no way to hardwire PCI devices, so you'll probably have to just > change which card is referenced in your scripts. I can see that that would be fun if I were to switch from 3.4-STABLE to 4.0-STABLE on my 7-NIC (8-port) router. Currently they all probe in a way that the physical layout of the cards mirrors the logical layout. One is a dual-port NIC with PCI bridge which would constitute a PCI bus all by itself, then I believe there are three separate PCI busses of three slots each for a total of 9 PCI slots (or it could be 4x2 and 1x1). I can just imagine a physical to logical mapping nightmare of 2-3-4-7-8-9-1-2-3 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-hackers" in the body of the message
Re: if_fxp - the real point
On Wed, 28 Mar 2001, Dennis wrote: > At 04:22 PM 03/28/2001, Chistopher S. Weimann wrote: > >On Wed, Mar 14, 2001 at 12:33:21PM -0500, Dennis wrote: > > > > > > Your logic is backwards. You think that rewarding mediocre companies will > > > scare good companies into wanting a piece of the pie. The only thing that > > > it will do is consume these companies so that the good companies can > > have a > > > larger share of the more profitable sun/NT market, and convince them that > > > they want no part of the "free" market if they have to compete with > > > cut-rate hardware from hungry companies. > > > > > > >Ok, let me get this Free Market thing straight. > > > >Not buying from a good company that provides a useful product > >and instead buying from a bad company that doesn't provide a > >useful product will make things better. > > > >That seems to be what you are saying dennis. > > > No, I said just the opposite. This was in response to someone > suggesting that we boycott companies like Intel for not providing > full disclosure on their boards, and reward companies that do by > touting their products. > > So I said that promoting lesser products because they are > "cooperative" will make good hardware less available to the > freebsd community, which might make some little people feel > powerful but it wont serve the user base, which I assume is the > goal. You seem to keep inferring that all vendors who disclose full programming information somehow have "lesser" hardware. Sure, there is plenty of crap out there that happens to have full programming information for it. There is also lots of good stuff that has full programming information. The Alteon Tigon and Tigon 2 are perfect examples (and very relevant to this discussion, since it seems to have started over the Intel Gigabit Ethernet adapters), and Alteon seems to have disclosed more than enough information to allow Bill Paul to write an extremely good driver. They actually went so far as to release the _firmware_ code for the board (how many vendors do you know of who do THAT?) so that Bill could tweak it as he saw fit, rather than having to use "black-box" firmware like most other vendors supply. This, to me, actually makes the Alteon Tigon Gigabit Ethernet chipsets a far, far BETTER product than the Intel Gigabit Ethernet chipsets. Intel in this case is the "lesser" hardware vendor which also happens to be a pain in the ass when it comes to getting programming information. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/rc.network and natd_enable
On Thu, 3 May 2001, Nick Rogness wrote:
> In 4.2-STABLE, /etc/rc.network has entries to turn on natd.
> However, natd does not get enabled if you don't specify
> natd_interface. WHat if you you have setup stored in a
> configuration file and do not wish to supply an interface flag in
> /etc/rc.conf? Well, natd does not turn on!
I've attached a very simple, but untested patch that will DTRT.
Anyone care to commit this if Nick says it works as expected?
Just in case the attachment doesn't make it, here it is inline (be
careful of cut'n'paste tab-to-space conversions).
--- rc.network.orig Thu May 3 17:04:05 2001
+++ rc.network Thu May 3 17:18:52 2001
@@ -269,7 +269,9 @@
else
natd_ifarg="-n
${natd_interface}"
fi
+ fi
+ if [ -n "${natd_interface}" -o -n
+"${natd_flags}" ]; then
echo -n ' natd';
${natd_program:-/sbin/natd} ${natd_flags} ${natd_ifarg}
fi
;;
-- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED]
FreeBSD: The fastest and most stable server OS on the planet.
For IA32 and Alpha architectures. IA64, PPC, and ARM under development.
http://www.freebsd.org
--- rc.network.orig Thu May 3 17:04:05 2001
+++ rc.network Thu May 3 17:18:52 2001
@@ -269,7 +269,9 @@
else
natd_ifarg="-n
${natd_interface}"
fi
+ fi
+ if [ -n "${natd_interface}" -o -n
+"${natd_flags}" ]; then
echo -n ' natd';
${natd_program:-/sbin/natd} ${natd_flags} ${natd_ifarg}
fi
;;
Re: FreeBSD 4.3 crashing with USB hub attached...
On Sat, 12 May 2001, Shannon Hendrix wrote: > On Fri, May 11, 2001 at 07:54:26PM -0400, Shannon wrote: > > > For the second boot I unplugged the USB hub. This time everything was > > fine... I'm sending this mail from the FreeBSD machine's console. > > Replying to my own post: > > The problem is the Logitech joystick, not the hub itself. Every time I > boot with the joystick plugged in, FreeBSD 4.3 pukes. I was about to ask you if it wasn't one of the devices plugged into the hub and not the hub itself. Glad I read the next message. :-) A friend of mine has a Saitek joystick that when plugged into his FreeBSD 4.3 system causes the same problems. I thought it was just another mis-behaved USB device and told him to keep it unplugged. He's not likely to use it with FreeBSD anytime soon, anyway. > The joystick is a force-feedback model (Logi Formula Force), but > is otherwise just your average every day USB joystick. IIRC, the joystick that my friend has is also force-feedback. Coincidence? I've got a force-feedback USB joypad that I can plug in and see if there are any problems. I haven't tried lately, though FreeBSD was happy with it when I tried a few months ago. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
On Mon, 14 May 2001, Shannon Hendrix wrote: > Did you notice, before the crash, that the kernel had some trouble > querying the offending device? That happens with me, and then a > little while later in the boot it crashes. Yes, the symptoms were the same as yours. The initial probing during boot took quite a while, and generated a few errors if I remember correctly, then a panic shortly afterwards. I'm going to try my USB joypad on my own 4.3-STABLE box tonight and see if I encounter any problems, since I just got a new OHCI USB controller for it (I was having what I can only explain as EMI/RFI problems with my on-board USB controller). I'll be going to my friend's place this weekend, so I can get details on what is happening with the joystick in question. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD 4.3 crashing with USB hub attached...
On Thu, 17 May 2001, Nick Hibma wrote: > If you could compile a kernel with debugging and debugger > > makeoptions DEBUG=-g > options DDB > > and then type > > trace > show registers > > and take it from there, that would be appreciated. Typing panic at the > debugger prompt creates a crashdump which you can then fish out of swap > space if you have dumpdev set in rc.conf. No problem, I'll do this tomorrow night or Saturday, hopefully. Luckily he's on a cable modem, so moving a big crashdump around shouldn't be a big problem (I'll set MAXMEM on the debug kernel to a much more reasonable amount than 256MB, too). :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Seeking recommendations for backup system
On Thu, 24 May 2001 [EMAIL PROTECTED] wrote: > I'm seeking recommendation for a backup system (software) that can > be used with a decent sized tape library, probably LTO based, and > FreeBSD 4.3-STABLE. > > I'm sure we could roll our based on freely available tools (eg. > Amanda) - but by now I'm used to Tivoli ADSM/TSM, and *like* the > convenience ADSM/TSM offers. We need the ability to make backups > (via Fast Ethernet) primarily of FreeBSD servers, but also > Solaris, Linux and HP-UX. Easy restore is important. > > (So why not buy TSM again? Primarily the price. We'll do it if we > have to, but would prefer something slightly less expensive and > also less complex.) I just mentioned this to someone else who asked a similar question elsewhere, but Veritas NetBackup (NOT BackupExec -- different animal) has a native FreeBSD 3.2 agent that works very well on FreeBSD 3.2 and up (I use it with 4.3-STABLE at the moment). They've got backup agents for a whole mess of platforms. You can also use any combination of NT, Solaris, Linux, and HP-UX servers. You've pretty much got the run of the park on that one. :-) If you call up Veritas, they should be more than happy to send you a time-limited (90 days, IIRC) demo. I asked for one before we decided to buy it and they shipped the CDs and demo license keys to me next-day. :-) -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why two cards on the same segment...
On Thu, 26 Jul 2001, Jonathan M. Slivko wrote: > Yes, but, I think the issue with the 2 IP classes working is > because one is not routable, and therefore it's not a real > IP address, and the router knows this, hence it's not reacting to > it by stopping to work. As long as you use virtual ip's > (192.168.*.*) then there should be no reason why it wouldn't work. > However, if your talking about a routable IP address, then you > might have a problem, as there is a difference between a virtual > IP address and a real (routable) IP address. Just my 0.02 cents. > -- Jonathan There is no difference. An RFC1918 address is just as real as any other IP address as far as any IP stack or network is concerned. The difference is that we, as humans, have decided those addresses are not to cross certain boundaries, and it is up to us to make sure they don't. Except for my edge router, my other routers could care less that I'm using RFC1918 addresses and in fact they don't know any better. I could just as easily stick my 207.160.213 network, another "real" network, on there right alongside the 207.160.214 network (and I did, at one time) with no problems. -- 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 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why two cards on the same segment...
On Thu, 26 Jul 2001, Matt Dillon wrote: > I wish it were that easy. If you have two interfaces on the same LAN > segment, but one is configured with an internal IP and one is > configured with an external IP, and the default route points out the > interface configured with the external IP, then you are ok. > > If you have one interface with *two* ip addresses. For example (taking > a real life example): > > ash:/home/dillon> ifconfig > fxp0: flags=8843 mtu 1500 > inet 208.161.114.66 netmask 0xffc0 broadcast 208.161.114.127 > inet 10.0.0.3 netmask 0xff00 broadcast 10.0.0.255 > ether 00:b0:d0:49:3b:fd > media: Ethernet autoselect (100baseTX ) > status: active > > Then the 'source IP' address the machine uses is completely up in the > air. It could be the external IP, or the internal IP, and it could > change out from under you if you manipulate the interface with ifconfig. > You have to explicitly bind to the correct source IP if you care. > > For our machines I bind our external services specifically to the > external IP. Beyond that I usually don't care because I NAT-out our > internal IP space anyway, so any packets sent 'from' an internal IP > to the internet wind up going through the NAT, which hides the fact > that the source machine chose the wrong IP. Hmm.. That hasn't been my experience at all. I have _always_ seen outgoing connections use a source address of the closest interface address that exists on the same IP network as the destination, OR, if it is a non-local destination, then the source is whatever IP address is on the same IP network as the next-hop gateway. If your next-hop gateway is an RFC1918 address, then your source address will be your RFC1918 address on the same subnet, unless you specify otherwise of course. Maybe if you set net.inet.ip.subnets_are_local to 1, then maybe the system will use the primary non-alias address of the closest physical interface, be it a public address or whatever, but I've not tried that. -- 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 (Itanium), PowerPC, and ARM architectures under development - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GATEKEEPER.MCAST.NET again (unexpected traffic)
On Mon, 10 May 2004, TSaplin Mikhail wrote: > On Monday 10 May 2004 12:31, you wrote: > > On Sun, 9 May 2004, TSaplin Mikhail wrote: > > > Recently I wrote, that I have litle traffic to GATEKEEPER.MCAST.NET, > > > (tcpdump show this: > > > 20:32:41.496039 129dial.supernet.kz.52075 > GATEKEEPER.MCAST.NET.1718: > > > udp 31 ) > > I know that H.323 protocol is used by ip-phones and releated > software. And i don't understand why it sitting on my clean system > (i've installed it without packages, except ltmdm(modem driver)). It just dawned on me that you are connected to your ISP when you see this, and those packets are probably coming from someone _else_ (you were probably not 129dial.supernet.kz when you saw these). Depending on your ISP's network configuration, you may see multicast and broadcast packets generated by other users. Generally harmless. -- 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-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GATEKEEPER.MCAST.NET again (unexpected traffic)
On Sun, 9 May 2004, TSaplin Mikhail wrote: > Recently I wrote, that I have litle traffic to GATEKEEPER.MCAST.NET, > (tcpdump show this: > 20:32:41.496039 129dial.supernet.kz.52075 > GATEKEEPER.MCAST.NET.1718: udp 31 > ) > > David Malone <[EMAIL PROTECTED]> on my question wrote: > >Does sockstat show which process is using port 52075? > No, sockstat show nothing about this. > > I've installed new system due express installation - but packets is steel > going. > > Maybe this is going on your 5.1 system, and is this right? Those are multicast UDP packets being sent by an H.323 endpoint application trying to find a local H.323 gatekeeper. Since they are multicast, they will stay within your LAN unless you have explicitly configured a router or tunnel to carry them out of it. Totally harmless, unless you really don't want any H.323-enabled applications installed and running. Use sockstat to look for anything listening on the 224.0.1.41 (gatekeeper.mcast.net) address. -- 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-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Request for Review: UFS2 Snapshot Management Environment
On Fri, 3 Sep 2004, Matthew N. Dodd wrote: On Fri, 3 Sep 2004, Ralf S. Engelschall wrote: ... | $ cat /snap/home:hourly.1/rse/foo.txt /snap/home:hourly.0/rse/foo.txt foo.txt Now you just need to hack sys/kern/vfs_lookup.c to do the right thing when you ask for /path/.snapshot. I recently set up a FreeBSD 5.3 box running Samba to hold all of our Windows users home directories. I've already had to restore a few files from the daily backups because somebody hosed their files in one way or another. Having hourly snapshots like this will be great. Currently I will have to set up special Samba access to the snapshot area which will make using them a bit harder, but having a '.snapshot' directory inside each directory would be ideal. Great work! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Protection from the dreaded "rm -fr /"
On Sat, 2 Oct 2004, Greg Black wrote: As for protecting against "rm -rf / foo" as a typo for "rm -rf /foo", I don't mind if we offer protection against that; but I see no reason at all to "protect" root from "rm -rf /". It's fair to say that somebody who types that means it, and it's fair to go as far as we can in satisfying it. I think you just nailed it on the head right here... if you say "rm -rf /" you probably mean it, but if you say "rm -rf / foo" you probably oopsed (pretty good bet, since rm / makes asking to rm foo redundant). How about checking if there is more than one argument, and if one of those arguments is "/", fail. If there is only one argument, even if it is "/", assume the user knows what he is doing and proceed normally. -- 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-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: smartmontools vs HP Smart Array 642 controller
On Wed, 23 Feb 2005, Brian Reichert wrote: Does anyone have any experience with smartctl and a HP Smart Array 642 controller? Your problem with smartmontools doesn't seem to be limited to the Smart Array 642, I just tried it on a DL380 G3 with the Smart Array 5i+ and got the same error you did. It appears to be a driver-specific problem. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp patch - bundling receive interrupts
On Wed, 24 Oct 2001, Marko Zec wrote: > The microcode should work on many revisions - if not all - of > Intel 8255* chipset, but the BSD driver is currently tested only > on 82558-B0, so I would really appreciate any feedback on driver > functionality/stability on other chipset revisions. Chalk up another 82558B that it works on. I started using it shortly after you mentioned this patch a couple of days ago and haven't experienced any problems. While doing a large file transfer between two FreeBSD boxes, performance definately did not suffer. I got 11MB/sec over FTP. When communicating with a Windows NT server over SMB, though, performance was bad (max 1.2MB/sec). I haven't yet checked to see if this is because of the interrupt coalescing or if it is just because Windows sucks. I did notice a 33% decrease in interrupts (if about 900 packets came in, about 600 interrupts were generated), so it definately worked. If I get real brave I might try it on my router which has mostly 82558B's but also an 82559 or two. -- 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-hackers" in the body of the message
Re: system halt
On Tue, 11 Dec 2001, Dmitry Mottl wrote: > This is from /var/run/dmesg.boot > == > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 > sio0: type 8250 > == > > When I write > cu -l /dev/cuaa0 > > system halts (console/network is not working at all) > > What happens? > How can I aid this? You have the serial port disabled in the BIOS, or not set to the I/O port and IRQ that FreeBSD is expecting. Enable it in the BIOS and make sure the BIOS and FreeBSD agree about the settings by changing one or the other. I'm not sure exactly why this causes FreeBSD to freeze, but I have come across the problem as well. It is definately a hardware problem with an unfortunate software side-effect. -- 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-hackers" in the body of the message
Re: USB "Memorybird" quirks
On Sat, 9 Feb 2002, Oliver Fromme wrote: > I think that would be a very good idea. The boot software issue > is negligible, because there aren't any USB devices you can boot > from. You mean can't boot from USB devices in just FreeBSD, or anywhere? I've not actually tried it yet, but many motherboard vendors have added the ability to boot from USB ZIP drives and probably other USB mass storage devices to their BIOSes, so it at least should be possible. -- 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-hackers" in the body of the message
Re: Ugly Huge BSD Monster
On Mon, 1 Sep 2003, Denis Troshin wrote: > Almost every package I install requires a few other packages. This > 'idea of using dependent packages' turns FreeBSD (and other > unix-systems) to an ugly monster. At least the dependencies are taken care of for you automatically in FreeBSD, unlike some systems which require you to download and install each depedency manually. > For example, I don't need Perl or Python but a few packages I > install require them. > > Does exist a programming under unix without these dependencies? > > P.S. Under Windows it is possible to write not bad applications > which depend just on libraries (KERNEL32, USER32, GDI32). And these > libs exist on every base system!!! I have to deal with creating internal distribution packages for all kinds of Windows software just about every day, and the dependencies for Windows software can be much worse, especially for Microsoft's own software which seems to be among the worst. Microsoft Office XP alone depends on (when installed on a base Windows 98SE installation), no less than Microsoft Installer 2.x (MSI), Internet Explorer 6, MDAC, and several other non-Office bits and pieces that don't come to mind right now. Granted, they are included in the Office XP installer and it will install all of this by itself if you don't have any of them installed, but they are indeed separate depedencies. I break as many depedencies as I possibly can out of a particular piece of software into separate distribution packages with their own dependency chains. The FreeBSD ports/packages system just happens to already do this to a high degree, because it is a good idea. -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest and most stable server OS on the planet - Available for IA32, IA64, PC98, Alpha, and UltraSPARC architectures - x86-64, PowerPC, ARM, MIPS, and S/390 under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Fri, 21 Jun 2002, Terry Lambert wrote: > It has functionality that can not be implemented without adding to > how UNIX does things. Basically, it needs to be able to hook the > account constructor/destructor. It's quite simple to integrate Cyrus IMAP with the local system. Cyrus will by default use the system password database for its authentication, all that is left is to write up a script to your liking to manage the IMAP folders (I wrote one in PERL using the IMAP::Admin and Mail::IMAPClient modules, but please don't ask me for them, I'm not that proud of them :-). You can hook that script in to whatever you're using to create the system user accounts. In the near future, however, I plan to move the authentication database into LDAP and have Cyrus use that so that I can get rid of all of the local system accounts which are there for nothing other than authentication (the shells are just /sbin/nologin). All in all, I love the Cyrus design, and it hasn't given me a bit of trouble in over 6 years. It makes doing a secure "black-box" mail server very easy. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net 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 No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD on a MaxAttach?
On Thu, 20 Jun 2002, Kip Macy wrote: [...snip...] > Maxtor has moved from FreeBSD to the Windows SAK so the newer boxes > are likely to have full BIOS support (they could not keep any of the > CDS developers to maintain the FreeBSD code base). Maybe they all went to work for Quantum. :-) We have some Quantum SNAP Servers which are exactly the same thing as the older MaxAttach boxes except with bigger IDE drives, and they're still running the custom version of FreeBSD on them. They actually perform better than our much heftier Windows NT 4 servers. They even perform better than the newer MaxAttach boxes which are now running a form of Win2K and have much heftier hardware. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net 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 No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Fri, 21 Jun 2002, Terry Lambert wrote: > Chris Dillon wrote: > > On Fri, 21 Jun 2002, Terry Lambert wrote: > > > It has functionality that can not be implemented without adding to > > > how UNIX does things. Basically, it needs to be able to hook the > > > account constructor/destructor. > > > > It's quite simple to integrate Cyrus IMAP with the local system. > > Cyrus will by default use the system password database for its > > authentication, > > While I appreciate the positive support of Cyrus, I guess I need to > point out that this approach only works if you are willing to send > passwords over the wire in plaintext. Yes, but this is the case with any IMAP server and doesn't really have anything to do with Cyrus in particular. Unlike other IMAP servers, however, Cyrus supports SASL which offers plenty of non-plain-text authentication options, unfortunately none of which work with a local FreeBSD password database that I know of. There is always the option to use SSL, which is my preference, but unfortunately neither SSL nor SASL have widespread IMAP client support yet. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net 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 No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD on a MaxAttach?
On Fri, 21 Jun 2002, Terry Lambert wrote: > Uh... the version of FreeBSD on the Quantum boxes is probably the > same version of FreeBSD that was on the InterJets... *cough*. 2.2.something? :-) Whatever version it is, I'm impressed with how well it works. The only problem I have with the Quantum SNAP boxes is the total lack of being able to script any kind of setting of file ownerships or ACLs. You have to set those entirely through the web interface, which is entirely unacceptable when you want to do it for 2000 user home directories. The NT command-line ACL tools don't work, which is how I script that kind of thing on NT servers, and I've tried in vain to write a PERL script that actually accessed and parsed the web interface and sent back the appropriate POSTs. It almost works, but I gave up for the time being. The only other option would be to write something to run in the JVM that is on them, and I can't find any API documentation on setting file ownership or ACLs, not to mention I don't know Java well enough to write such a thing in the first place. :-) -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net 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 No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cyrus vs. UW IMAP (was: Re: I Volunteer)
On Sat, 22 Jun 2002, Neil Blakey-Milner wrote: > On Sat 2002-06-22 (00:06), Chris Dillon wrote: > > Yes, but this is the case with any IMAP server and doesn't really > > have anything to do with Cyrus in particular. Unlike other IMAP > > servers, however, Cyrus supports SASL which offers plenty of > > non-plain-text authentication options, unfortunately none of which > > work with a local FreeBSD password database that I know of. > > Courier-IMAP supports SASL (PLAIN, LOGIN, CRAM-MD5, CRAM-SHA1). I should have said "unlike some other IMAP servers". Thanks to the simple BSD-like license on the Cyrus SASL implementation, it has found its way into a lot of places. > > There is always the option to use SSL, which is my preference, but > > unfortunately neither SSL nor SASL have widespread IMAP client > > support yet. > > Most IMAP clients I know of support SSL. Outlook, Outlook Express, > Eudora, Netscape, Evolution, mutt, pine, ... I know Netscape didn't have that ability for a long time, and neither did Outlook or OE. Mutt and Pine have had it since around 1999, though. > Which IMAP clients don't? If all of the above now support SSL for IMAP connections, then I can't think of any. -- Chris Dillon - cdillon(at)wolves.k12.mo.us - cdillon(at)inter-linc.net 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 No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to control tagged queueing?
On Tue, 12 Nov 2002, Dan Ellard wrote: > I'm experimenting with the effects of SCSI tagged queueing on file > system performance. Is there any kind of global toggle somewhere in > the kernel to turn tagged queueing on and off, and/or knob to limit > the number of outstanding tags? Tagged queue management all seems > to be done at the device level, and I haven't found hooks for > controlling it at a higher level (but I thought I'd ask before > running off to write something). > > I'm running 4.6.2p4, in case things have changed. (If there's a > nicer interface in 4.7, I'll install it immediately!) man camcontrol Specifically: camcontrol tags [device id] [generic args] [-N tags] [-q] [-v] camcontrol negotiate [device id] [generic args] [-T enable|disable] -- Chris Dillon - cdillon(at)wolves.k12.mo.us FreeBSD: The fastest and most stable server OS on the planet - Available for IA32 (Intel x86) and Alpha architectures - IA64, PowerPC, UltraSPARC, ARM, and S/390 under development - http://www.freebsd.org No trees were harmed in the composition of this message, although some electrons were mildly inconvenienced. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Wed, 21 Jul 1999, Kip Macy wrote: > My employer has gone through numerous motherboards, we have found the ASUS > P2B (now the P2B-F) to be rock solid for Pentium II usage. This is probably more appropriate for -hardware or even just -chat.. but anyway, I'll second that recommendation. I've found the ASUS P2B series to be very solid. I've also used many ATrend BX boards for Winblows95 boxes (simply because they were cheaper than the ASUS boards), and haven't had a bit of trouble with them. YMMV. -- Chris Dillon - cdil...@wolves.k12.mo.us - cdil...@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare: porting kernel modules to FreeBSD
On Wed, 18 Aug 1999, Mark Huizer wrote: > Hi there, > > I had a look recently at the code for one of the kernel modules that VMWare > requires (driver-only.tar), and it looks like something that should be > portable to FreeBSD, although there is some messy stuff in it (assembly > that seems to be using Linux specific stuff, brrr..) But anyway: it > looks feasable. > > Is anyone already working on this, or are some people interested in > helping with this? > > As far as I can see, the linux emulation is good enough to run the > vmware program, "all" you need to do is implement /dev/vmmon and > /dev/vmnet, given the fact that the code is written really unportable, > so there is some rewriting to be done. Then with the KLD's > vmmon,vmnet and linux you should be able to run vmware. WooHoo! Well, I can't celebrate quite yet, but I'll definately be buying a copy of VMWare if anyone gets this to work (WAY above my head, so no help from me, sorry). More than likely, many people other than myself would also buy a copy of VMWare for Linux just to run under FreeBSD, so maybe you can convince VMWare, Inc. to give you or whoever else decides to tackle this some monetary compensation? It would also help to bring us a step closer to a native FreeBSD version of VMWare, since some (most?) of the work would already be done for them (the porting of vmmon and vmnet). -- Chris Dillon - cdil...@wolves.k12.mo.us - cdil...@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Bill Studenmund wrote: > On Tue, 17 Aug 1999, Brian C. Grayson wrote: > > > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > > A group of us at Apple are trying to figure out how to handle > > > situations where a filesystem with "foreign" user ID's are present. > > > > Have you looked at mount_umap(8)? I (naively) think it would > > solve most of your concerns. > > I don't think so. umap is for translating credentials between domains. I > think what Fred wants to do is different, and that is to ignore the > credentials on the system. > > Fred, right now what happens in MacOS when I take a disk which has sharing > credentials set up, and hook it into another machine? How are the > credentials handled there? > > Also, one of the problems which has been brought up in the thread is that > umap needs to know what credentials to translate to. For that, we'd need > to stash the credentails on the drive. I'm probably being extremely naive myself, but I just envisioned a scenario like this (pardon me if someone else has already suggested this): When a filesystem is mounted as foreign (HOW that is determined I won't talk about), every file in the filesytem has its credentials mapped to that of the mountpoint. File mode bits are not remapped in any way. New files gain the credentials of their _foreign_ parent. That's the skinny. Now I'll give a (much longer) example to clarify. An origin filesystem (created by and mounted on the same system) which happens to have stuff owned by several different users (this is all pseudo... don't mind sizes, dates, and link counts in this example): drwxr-xr-x 4 root wheel512 Aug 18 15:42 ./ drwxr-x--- 4 harry users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users512 Jul 1 18:40 dir2/ ls -la dir1 -rw-r- 1 harry users0 Aug 18 15:48 bar -rw-r- 1 harry users0 Aug 18 15:48 foo Take this filesystem and mount it as a "foreign" filesystem on another machine. User 'jake' owns the mountpoint on the machine. drwxr-xr-x 2 jake users512 Jan 4 1999 /mnt/ mount_foreign /dev/whatever /mnt ls -la /mnt drwxr-xr-x 4 jake users512 Aug 18 15:42 ./ drwxr-x--- 4 jake users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 jake users512 Jul 1 18:40 dir2/ ls -la /mnt/dir1/ -rw-r- 1 jake users0 Aug 18 15:48 bar -rw-r- 1 jake users0 Aug 18 15:48 foo Note file mode bits were not affected, but everything gained the user/group of the mountpoint. Now what happens if user 'jake' adds something to the filesystem? touch /mnt/dir1/baz ls -la /mnt/dir1/ -rw-r- 1 jake users0 Aug 18 15:48 bar -rw-r- 1 jake users0 Aug 18 15:48 foo -rw-r- 1 jake users0 Aug 18 15:50 baz
Re: sysinstall, GJOURNAL and ZFS
Quoting Dmitry Morozovsky : Well, I can see at least one rather big problem with bgfsck (or with snapshots to be more precise): inappropriate time of file system lock on snapshot creation. On not-too-big 300G ufs2 not-too-heavy loaded snapshot creation time is 20+ minutes, and 5+ from that file system blocked even on reads. This looks unacceptable for me for any real use. The snapshot time depends heavily on the I/O throughput of your disk subsystem. On a several year old system with 5 x 72GB 15KRPM U320 SCSI drives in a RAID5 array, a fairly well loaded 260GB filesystem (90GB used, 354K out of 8M inodes used, and several hundred MB to a GB of changes per day) completes a snapshot in exactly 2 minutes. 2 minutes is still too long to be blocking I/O in the middle of the day when it is being actively used, so I just take 1 snapshot per day while it is idle. I would love to put ZFS on this system so that I could have finer grained snapshots, but I need user quota support which our ZFS currently lacks. -- 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-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: P5 vs Celeron vs PII
On Thu, 10 Jun 1999, Dennis wrote: > > In a nutshell, does anyone have a handle on the relative preformance of > these are? > > 233Mhz P5 vs 233Mhz Celeron 233MHz P5 (w/L2 cache on motherboard) > 233MHz Celeron (no L2 cache) > 333Mhz Celeron vs 333 Mhz PII In my experience, the Celeron CPUs which have the 128KB full-speed cache are pretty much on-par (though not always) with the PII CPUs with 512KB half-speed cache. I have noticed that in certain computationally-heavy situations that the smaller Celeron cache hurts (cracking a password with John The Ripper, for instance), even though it runs at a higher clock rate. Last time I looked, the price difference was enough that the Celeron gives you more bang for the buck. -- Chris Dillon - cdil...@wolves.k12.mo.us - cdil...@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Wed, 21 Jul 1999, Kip Macy wrote: > My employer has gone through numerous motherboards, we have found the ASUS > P2B (now the P2B-F) to be rock solid for Pentium II usage. This is probably more appropriate for -hardware or even just -chat.. but anyway, I'll second that recommendation. I've found the ASUS P2B series to be very solid. I've also used many ATrend BX boards for Winblows95 boxes (simply because they were cheaper than the ASUS boards), and haven't had a bit of trouble with them. YMMV. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: VMWare: porting kernel modules to FreeBSD
On Wed, 18 Aug 1999, Mark Huizer wrote: > Hi there, > > I had a look recently at the code for one of the kernel modules that VMWare > requires (driver-only.tar), and it looks like something that should be > portable to FreeBSD, although there is some messy stuff in it (assembly > that seems to be using Linux specific stuff, brrr..) But anyway: it > looks feasable. > > Is anyone already working on this, or are some people interested in > helping with this? > > As far as I can see, the linux emulation is good enough to run the > vmware program, "all" you need to do is implement /dev/vmmon and > /dev/vmnet, given the fact that the code is written really unportable, > so there is some rewriting to be done. Then with the KLD's > vmmon,vmnet and linux you should be able to run vmware. WooHoo! Well, I can't celebrate quite yet, but I'll definately be buying a copy of VMWare if anyone gets this to work (WAY above my head, so no help from me, sorry). More than likely, many people other than myself would also buy a copy of VMWare for Linux just to run under FreeBSD, so maybe you can convince VMWare, Inc. to give you or whoever else decides to tackle this some monetary compensation? It would also help to bring us a step closer to a native FreeBSD version of VMWare, since some (most?) of the work would already be done for them (the porting of vmmon and vmnet). -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures (SPARC under development). ( http://www.freebsd.org ) "One should admire Windows users. It takes a great deal of courage to trust Windows with your data." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Need some advice regarding portable user IDs
On Wed, 18 Aug 1999, Bill Studenmund wrote: > On Tue, 17 Aug 1999, Brian C. Grayson wrote: > > > On Tue, Aug 17, 1999 at 07:17:45PM -0700, Wilfredo Sanchez wrote: > > > A group of us at Apple are trying to figure out how to handle > > > situations where a filesystem with "foreign" user ID's are present. > > > > Have you looked at mount_umap(8)? I (naively) think it would > > solve most of your concerns. > > I don't think so. umap is for translating credentials between domains. I > think what Fred wants to do is different, and that is to ignore the > credentials on the system. > > Fred, right now what happens in MacOS when I take a disk which has sharing > credentials set up, and hook it into another machine? How are the > credentials handled there? > > Also, one of the problems which has been brought up in the thread is that > umap needs to know what credentials to translate to. For that, we'd need > to stash the credentails on the drive. I'm probably being extremely naive myself, but I just envisioned a scenario like this (pardon me if someone else has already suggested this): When a filesystem is mounted as foreign (HOW that is determined I won't talk about), every file in the filesytem has its credentials mapped to that of the mountpoint. File mode bits are not remapped in any way. New files gain the credentials of their _foreign_ parent. That's the skinny. Now I'll give a (much longer) example to clarify. An origin filesystem (created by and mounted on the same system) which happens to have stuff owned by several different users (this is all pseudo... don't mind sizes, dates, and link counts in this example): drwxr-xr-x 4 root wheel512 Aug 18 15:42 ./ drwxr-x--- 4 harry users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users512 Jul 1 18:40 dir2/ ls -la dir1 -rw-r- 1 harry users0 Aug 18 15:48 bar -rw-r- 1 harry users0 Aug 18 15:48 foo Take this filesystem and mount it as a "foreign" filesystem on another machine. User 'jake' owns the mountpoint on the machine. drwxr-xr-x 2 jake users512 Jan 4 1999 /mnt/ mount_foreign /dev/whatever /mnt ls -la /mnt drwxr-xr-x 4 jake users512 Aug 18 15:42 ./ drwxr-x--- 4 jake users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 jake users512 Jul 1 18:40 dir2/ ls -la /mnt/dir1/ -rw-r- 1 jake users0 Aug 18 15:48 bar -rw-r- 1 jake users0 Aug 18 15:48 foo Note file mode bits were not affected, but everything gained the user/group of the mountpoint. Now what happens if user 'jake' adds something to the filesystem? touch /mnt/dir1/baz ls -la /mnt/dir1/ -rw-r- 1 jake users0 Aug 18 15:48 bar -rw-r- 1 jake users0 Aug 18 15:48 foo -rw-r- 1 jake users0 Aug 18 15:50 baz >From jake's perspective, this happens as if it were an origin filesystem and he owned everything on it. Now, mount the filesystem again on it's origin system. drwxr-xr-x 4 root wheel512 Aug 18 15:42 ./ drwxr-x--- 4 harry users512 Mar 10 10:21 dir1/ drwxr-xr-x 2 john users512 Jul 1 18:40 dir2/ Nothing changed here as far as credentials are concerned. ls -la dir1 -rw-r- 1 harry users0 Aug 18 15:48 bar -rw-r- 1 harry users0 Aug 18 15:48 foo -rw-r- 1 harry users0 Aug 18 15:50 baz The new file added by the foreign user inherited the credentials of its origin parent, just as it would have normally. Points to ponder: 1) When writing to a foreign filesystem, should file mode bits be inherited from the parent, or be based on the umask of the foreign user writing the file at that time? Can the umask of the foreign owner be preserved (which isn't necessarily the same thing as inheriting from the parent) and used? 2) How should chown and chgrp act when attempting to modify credentials on one of these foreign filesystems? Should it affect only the local credential mapping (temporarily) and not modify the foreign filesystem? Should you completely ignore the attempts and not do anything? I vote for temporarily changing credentials (until unmounted), but that is certainly a lot harder to implement than just ignoring the changes. :-) 3) What happens if you want to mount the filesystem on a machine besides the origin, but you do NOT want to do credential mapping (i.e. the systems both have the same sets of users)? This wouldn't matter if you just used a mount option or different filesystem type when mounting, but I'm assuming something automagic is wanted here. 4) What happens if you change the credentials of the mountpoint after you have mounted the foreign filesystem? Should the mappings follow the new credentials, or stay as they were when first mounted? Even if I have no idea what I'm ta
