Re: Problems with Ethernet programming
On Thursday, 13 May 1999 at 13:32:42 +0400, Pavel V. Antipov wrote: Now I want to send this packet into the Ethernet network and recieve it of destination computer. Please, tell me how can i write/read the Ethernet packet. Use the bpf device. You may have to recompile the kernels to support this. If you want to look at source code, try nmap (I think it uses a modified libpcap on top of BPF, but it will still show you how to do this kind of stuff). -- Dr Graham Wheeler E-mail: g...@cdsec.com Citadel Data Security Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Internet/Intranet Network Specialists Data Security Products WWW:http://www.cdsec.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
large master.passwd
Hi On a site with 20k users in the master.passwd, and where NIS is not trusted, the master.passwd is distributed to each workstation. The pwd.db and spwd.db are sized around 10Mb. Sometimes, those .db files get corrupt. I suspect it has something to do with the machines being reset etc before the sync is finished. (The machines are dual-boot, and there are a lot of users around.) I did some patching, and have not seen corrupted .db-files since. So how usable is this patch? Worth intregrating? Regards, Roar Thronæs --- ../../3.1-RELEASE/src/usr.sbin/pwd_mkdb/pwd_mkdb.c Tue Apr 20 09:52:58 1999 +++ pwd_mkdb.c Tue Apr 20 11:07:53 1999 @@ -71,7 +71,7 @@ 4096, /* bsize */ 32, /* ffactor */ 256,/* nelem */ - 2048 * 1024,/* cachesize */ + 8192 * 1024,/* cachesize */ NULL, /* hash() */ 0 /* lorder */ }; @@ -457,6 +457,10 @@ /* Set master.passwd permissions, in case caller forgot. */ (void)fchmod(fileno(fp), S_IRUSR|S_IWUSR); + /* sync may be wise + -roart */ + sync(); + /* Install as the real password files. */ (void)snprintf(buf, sizeof(buf), %s/%s.tmp, prefix, _MP_DB); (void)snprintf(buf2, sizeof(buf2), %s/%s, prefix, _MP_DB); @@ -477,6 +481,10 @@ */ (void)snprintf(buf, sizeof(buf), %s/%s, prefix, _MASTERPASSWD); mv(pname, buf); + + /* sync may be wise + -roart */ + sync(); /* * Close locked password file after rename() To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
superblock corruption
apropos the recent discussion on superblocks and whether they ever get corrupted, I just got a call from a friend. One of his cluster nodes had power-failed at a bad time, and fsck was indicating a superblock corruption problem. I told him about -b 32, which he had never had to use in four years of running a large cluster. This problem was so new to him that he in fact had never heard of the -b switch or the backup superblocks. He couldn't affort to lose what he had on this node, as he was in the middle of changing something and had not had a chance to back it up to a server. Backup superblocks are still a good idea, even when you only need them every few years. ron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
Kelly Yancey kby...@alcnet.com writes: Hmm. I sent this message a few days ago and it has been silently ignored. Should I consider that an OK to extern the get_mode_param function in vga_isa.c? Or should I take that as a mass go ahead, we're not going to commit the code anyway? :( Hmm, well, I don't like to say go ahead, we're not going to commit the code anyway, but I can't see the use of adding Mode X support - I feel that the gain in functionality is too small to justify the added complexity. You'll need to add bits to the video_info structure to describe the encoding. AFAIK, the current model can only describe linear and plane-per-channel encodings accurately, whereas Mode X uses a weird interlaced encoding. The designers of the VGA chipset ought to be taken out and shot. You'll need to hack everything that hooks into syscons but doesn't explicitly set the video mode to check for Mode X so they won't shoot themselves in the foot trying to address it as a linear mode. To summarize, it seems like a lot of trouble just to get 40 additional scanlines and square pixels on obsolete hardware - anything that doesn't support 'options VESA' was already obsolete five years ago. It's not going to make FreeBSD a better desktop OS (desktop users use X, not syscons) and its' not going to make FreeBSD a better server OS (no, a prettier splash screen does not make your server faster). OBTW, Mode Q has square pixels and linear addressing. I won't mind adding support for Mode Q :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: fsck and large file system
Mark J. Taylor mtay...@cybernet.com writes: The problem that we ran into in a system with several 130 MB RAID5 arrays is that the fsck was running out of RAM+swap. We had to add a vnode to swap to before the fsck would complete (basically added more swap space). We had to have over 100 MB swap space to fsck the 130 MB volume, and the system has 64 MB RAM. This was is 2.2.8 (haven't upgraded it yet). I *really* hope you meant 130 GB and not 130 MB :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[Fwd: SYN floods against FreeBSD]
Well..this is just something i picked off BugTraq..worths looking into?
If it's old news - pardon me...
--Ugen
---BeginMessage---
Here's a quickie for the people who have been plagued with high bandwidth
syn flood attacks, a kernel patch for FreeBSD 3.1-STABLE which rate limits
SYN processing. Its messy but functional and I don't have time to make it
better (thats the fbsd developers job, not mine :P), cd /usr/src/sys,
patch synlim, add options SYN_RATELIM (I highly recommend ICMP_BANDLIM
as well) to your kernel, recompile, and sysctl net.inet.tcp.synlim will be
available (default to 100). This is the maximium number of SYNs per second
that will be processed, the rest will be silently discarded. On my test
system (P2 450 running 3.1-stable being hit w/15,000 packets per sec),
this has successfully brought CPU usage from 100% to ~20% (against an open
port which is replying with unacknowledged ACKs).
Which brings us to the more sticky topic of kernel panics when under SYN
flood (which I believe to be the cause of some earlier posts from certain
people at Exodus Communications *cough*). Lord knows I found enough of
them when doing this testing, but the one that seems to be the biggie for
crashing when under syn flood is as follows (heh just turned off the
synlim and panic'd within 8 seconds while writing this):
panic: free: multiple frees
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:285
#1 0xc0138c09 in panic (fmt=0xc02192b7 free: multiple frees)
at ../../kern/kern_shutdown.c:446
#2 0xc0135aaf in free (addr=0xc0cdd600, type=0xc0239330)
at ../../kern/kern_malloc.c:333
#3 0xc01768f4 in ifafree (ifa=0xc0cdd600) at ../../net/route.c:262
#4 0xc0176876 in rtfree (rt=0xc34ce700) at ../../net/route.c:236
#5 0xc0176c84 in rtrequest (req=2, dst=0xc34cbac0, gateway=0xc34cbad0,
netmask=0x0, flags=393223, ret_nrt=0x0) at ../../net/route.c:536
#6 0xc017b34d in in_rtqkill (rn=0xc34ce700, rock=0xc0231610)
at ../../netinet/in_rmx.c:242
#7 0xc0176064 in rn_walktree (h=0xc0cd9e00, f=0xc017b2fc in_rtqkill,
w=0xc0231610) at ../../net/radix.c:956
#8 0xc017b3ec in in_rtqtimo (rock=0xc0cd9e00) at ../../netinet/in_rmx.c:283
#9 0xc013d19b in softclock () at ../../kern/kern_timeout.c:124
Which after a quick examination seems to be a perioditic routing table
cleanup. It seems that in_rtqtimo is scheduled to run every
net.inet.ip.rtexpire seconds (which is dynamicly adjusted and can never go
lower then net.inet.ip.rtminexpire). When the system is under heavy load
from processing lots of small packets (they don't even have to be SYNs,
anything which can get routed will do the trick, though the packet kiddies
would get very little gain from just sending an ip header since its going
to be padded to 64 bytes for the eth frame anyhow), this route cleanup
code will go wacking at routes it shouldn't and free some memory twice. In
the course of testing I've gotten my rtq_reallyold to -3 and seen lots of
tvotohz: negative time difference -2 sec 0 usec. Perhaps someone with
free time or more specific knowledge of this area would like to FIX IT? =)
Perhaps when I get more free time I'll test some other *nix's. I would
really recommend putting all this rate limiting code at an ipfw level.
If you would like to contact me regarding this please use
hum...@quadrunner.com (at least if you want a quick reply), thanks.
--
Richard Steenbergen hum...@lightning.net hum...@efnet PGP ID: 0x741D0374
PGP Key Fingerprint: C6EF EFA0 83B2 071F 1AB6 B879 1F70 4303 741D 0374
http://users.quadrunner.com/humble
*** conf/options.oldSat May 15 23:08:03 1999
--- conf/optionsSat May 15 23:40:21 1999
***
*** 68,73
--- 68,74
SYSVSHM opt_sysvipc.h
UCONSOLE
ICMP_BANDLIM
+ SYN_RATELIM
# POSIX kernel options
P1003_1B opt_posix.h
*** netinet/tcp_var.h.old Sat May 15 23:25:39 1999
--- netinet/tcp_var.h Sat May 15 23:45:05 1999
***
*** 40,45
--- 40,49
* Kernel variables for tcp.
*/
+ #ifdef KERNEL
+ #include opt_syn_ratelim.h
+ #endif
+
/*
* Tcp control block, one per tcp; fields:
* Organized for 16 byte cacheline efficiency.
***
*** 305,311
#define TCPCTL_RECVSPACE9 /* receive buffer space */
#define TCPCTL_KEEPINIT 10 /* receive buffer space */
#define TCPCTL_PCBLIST 11 /* list of all outstanding PCBs
*/
! #define TCPCTL_MAXID 12
#define TCPCTL_NAMES { \
{ 0, 0 }, \
--- 309,316
#define TCPCTL_RECVSPACE9 /* receive buffer space */
#define TCPCTL_KEEPINIT 10 /* receive buffer space */
#define TCPCTL_PCBLIST 11 /* list of all outstanding PCBs
*/
! #define TCPCTL_SYNLIM 12 /* Rate limiting of SYNs */
! #define TCPCTL_MAXID 13
#define TCPCTL_NAMES { \
{ 0, 0 }, \
***
*** 320,325
--- 325,331
Re: modex support (again)
On 14 May 1999, Dag-Erling Smorgrav wrote: Kelly Yancey kby...@alcnet.com writes: Hmm. I sent this message a few days ago and it has been silently ignored. Should I consider that an OK to extern the get_mode_param function in vga_isa.c? Or should I take that as a mass go ahead, we're not going to commit the code anyway? :( Hmm, well, I don't like to say go ahead, we're not going to commit the code anyway, but I can't see the use of adding Mode X support - I feel that the gain in functionality is too small to justify the added complexity. You'll need to add bits to the video_info structure to describe the encoding. AFAIK, the current model can only describe linear and plane-per-channel encodings accurately, whereas Mode X uses a weird interlaced encoding. The designers of the VGA chipset ought to be taken out and shot. You'll need to hack everything that hooks into syscons but doesn't explicitly set the video mode to check for Mode X so they won't shoot themselves in the foot trying to address it as a linear mode. To summarize, it seems like a lot of trouble just to get 40 additional scanlines and square pixels on obsolete hardware - anything that doesn't support 'options VESA' was already obsolete five years ago. It's not going to make FreeBSD a better desktop OS (desktop users use X, not syscons) and its' not going to make FreeBSD a better server OS (no, a prettier splash screen does not make your server faster). Shot definately :) You have a lot of good points. What really confuses me, I guess, is that support for 320x240 modex is already in there. I've poked around with it a bit when adding the other modes and noticed that it doesn't do anything but set the mode. I guess we are already in the boat of having a problem with people being able to shoot themselves in the foot :( My guess as to the logic is that if you set the mode to 320x240, you better expect to the interlacing. What I don't get is how the memory is presented to apps using the driver. The best I could think of would be to present it a 256k linear frame buffer with the pixels in order (ie writes to consecutive pixels would result in the driver switching planes), and while that would present a consistent interface, it would be *really* slow (if it is even possible). The next best thing would be to present it a 256k linear frame buffer but with each plane 64k after the previous. Applications would have to be aware of the layout (ie. know that modex modes aren't linear) because writes to consecutive memory addresses would result in changing every 4th pixel. This is the method I would assume must already be in place for the existing 320x240 mode, but I can't find it. Which means that at the moment 320x240 is useless? Really, I was thinking that this would be a neat thing to add. I could have some higher resolution video modes without needing VESA (and VM86). But you make a good point in that anyone who wants graphics uses X. I guess I was thinking that maybe the additional modes would be of use should FreeBSD ever really get an equivalent to libsvga. Anyway, as you point out, then the modes are really only of use to splash screens (which is a minor feature in and of itself). So the question becomes, is there any interest in adding 6 mode tweaked modes (in addition to the existing 320x240) or should we reduce complexity and remove the 320x240 mode because surely nothing can be using it (you can only write to every 4th pixel right now). OBTW, Mode Q has square pixels and linear addressing. I won't mind adding support for Mode Q :) Mode Q? I'm not familiar with that one. Presumably a less-than-320x200 resolution? Kelly Yancey ~kby...@alcnet.com~ FreeBSD - The Power To Serve - http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
Kelly Yancey kby...@alcnet.com writes: What I don't get is how the memory is presented to apps using the driver. The best I could think of would be to present it a 256k linear frame buffer with the pixels in order (ie writes to consecutive pixels would result in the driver switching planes), and while that would present a consistent interface, it would be *really* slow (if it is even possible). Yes, it's possible, but it requires a page fault on *every* write to video memory. YA case of 'possible, but not practical'. (this technique has been used to simulate a linear frame buffer when using paged modes, but I haven't yet succeeded in convincing Kazu to implement it in the VESA driver and I don't have the time or know-how to do it myself) The next best thing would be to present it a 256k linear frame buffer but with each plane 64k after the previous. Applications would have to be aware of the layout (ie. know that modex modes aren't linear) because writes to consecutive memory addresses would result in changing every 4th pixel. This is the method I would assume must already be in place for the existing 320x240 mode, but I can't find it. Which means that at the moment 320x240 is useless? Yes, if it's there at all you have to switch banks manually. Really, I was thinking that this would be a neat thing to add. I could have some higher resolution video modes without needing VESA (and VM86). The VESA code is very small, and you want VM86 anyway (amongst other things, for reliable memory detection) But you make a good point in that anyone who wants graphics uses X. I guess I was thinking that maybe the additional modes would be of use should FreeBSD ever really get an equivalent to libsvga. We already have that (libvgl), though it's in deperate need of maintenance. Anyway, as you point out, then the modes are really only of use to splash screens (which is a minor feature in and of itself). So the question becomes, is there any interest in adding 6 mode tweaked modes (in addition to the existing 320x240) or should we reduce complexity and remove the 320x240 mode because surely nothing can be using it (you can only write to every 4th pixel right now). I vote for the latter. OBTW, Mode Q has square pixels and linear addressing. I won't mind adding support for Mode Q :) Mode Q? I'm not familiar with that one. Presumably a less-than-320x200 resolution? No, actually it has 1536 more pixels :) Mode Q is so named because the frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) If you have time and talent to spare and want to work on the console code, I have two suggestions for useful additions: - modify syscons so userland software can mmap the frame buffer, and whatever other modifications are necessary to make it possible for userland software to use graphics without needing write access to /dev/kmem (currently, the only way to mmap the frame buffer is to map in the correct address range from /dev/kmem) - port GGI to FreeBSD. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: large master.passwd
In the last episode (May 14), Roar Thron?s said: On a site with 20k users in the master.passwd, and where NIS is not trusted, the master.passwd is distributed to each workstation. The pwd.db and spwd.db are sized around 10Mb. Sometimes, those .db files get corrupt. I suspect it has something to do with the machines being reset etc before the sync is finished. (The machines are dual-boot, and there are a lot of users around.) I did some patching, and have not seen corrupted .db-files since. So how usable is this patch? Worth intregrating? - 2048 * 1024,/* cachesize */ + 8192 * 1024,/* cachesize */ Cachsize is already adjustable via the -s commandline switch. + /* sync may be wise + -roart */ + sync(); How about an fsync() of only that file? (I don't remember whether fsync flushes metadata though) -Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
1GB, kvm issues.
It's been noted on several occasions that with large ( 256MB) of RAM, one has to be careful with the configuration (NMBCLUSTERS, MAXUSERS) to prevent the box from falling over every few days due to kvm problems. Can somebody be more specific? I'm just about to order a really, really expensive machine and I want to be sure I can get it to work .. :) Chuck Youse Director of Systems cyo...@cybersites.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
On 14 May 1999, Dag-Erling Smorgrav wrote: We already have that (libvgl), though it's in deperate need of maintenance. That what I meant by equivalent ;) Anyway, as you point out, then the modes are really only of use to splash screens (which is a minor feature in and of itself). So the question becomes, is there any interest in adding 6 mode tweaked modes (in addition to the existing 320x240) or should we reduce complexity and remove the 320x240 mode because surely nothing can be using it (you can only write to every 4th pixel right now). I vote for the latter. I'm starting to think that this is the Right Thing also. But then again, where is the line? I think removing the interlaced mode x modes might make sense...but why have any video modes outside of X? Just because we can? Does anything use libvgl? OBTW, Mode Q has square pixels and linear addressing. I won't mind adding support for Mode Q :) Mode Q? I'm not familiar with that one. Presumably a less-than-320x200 resolution? No, actually it has 1536 more pixels :) Mode Q is so named because the frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) Yeah, I've seen the DOS port of snes9x use that. I don't think it has truely square pixels though since the screen has a 4:3 aspect ratio and the resolution is 1:1...the pixels should look slightly wider than they are tall. But it is linear :) The question is...is it worth including? I just did a quick search on the net and found the register programming information for this one (256x256x256) and another interesting linear mode (296x220x256) which has almost square pixels and a slightly higher resolution. Finally, would there be any interest in 720x480x16 color VGA mode. I have some old code which does this fine and have seen several other references to it in my search for mode Q. This goes along with the question of where the line is before a video mode becomes useless. And if the verdict is that the extra video modes (so long as they are planar) are useful, then how about some tweaked text modes? We have support for a number of different rows, but I have some old patches (which need updating) for extending the number of text mode columns from 80 to 90. BTW, the extra advantage of 90 column text modes is that syscons mouse pointer doesn't suffer from the weird character cell wrapping which causes the mouse pointer to stretch by 1 pixel when it cross character cell boundaries (since each character cell in 90 column mode is 8 pixels wide not 9). If you have time and talent to spare and want to work on the console code, I have two suggestions for useful additions: - modify syscons so userland software can mmap the frame buffer, and whatever other modifications are necessary to make it possible for userland software to use graphics without needing write access to /dev/kmem (currently, the only way to mmap the frame buffer is to map in the correct address range from /dev/kmem) I would like to do this. But unfortunately, I am currently mostly lacking the talent :) However, I just received The Design and Implementation of 4.4 BSD so as soon as I feel I really understand how mmap'ing is implemented, I might take a whack at it. - port GGI to FreeBSD. I thought this had been discussed and shot down? Kelly Yancey ~kby...@alcnet.com~ FreeBSD - The Power To Serve - http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
On 14 May 1999, Dag-Erling Smorgrav wrote: Kelly Yancey kby...@alcnet.com writes: What I don't get is how the memory is presented to apps using the driver. The best I could think of would be to present it a 256k linear frame buffer with the pixels in order (ie writes to consecutive pixels would result in the driver switching planes), and while that would present a consistent interface, it would be *really* slow (if it is even possible). Yes, it's possible, but it requires a page fault on *every* write to video memory. YA case of 'possible, but not practical'. (this technique has been used to simulate a linear frame buffer when using paged modes, but I haven't yet succeeded in convincing Kazu to implement it in the VESA driver and I don't have the time or know-how to do it myself) The next best thing would be to present it a 256k linear frame buffer but with each plane 64k after the previous. Applications would have to be aware of the layout (ie. know that modex modes aren't linear) because writes to consecutive memory addresses would result in changing every 4th pixel. This is the method I would assume must already be in place for the existing 320x240 mode, but I can't find it. Which means that at the moment 320x240 is useless? Yes, if it's there at all you have to switch banks manually. Really, I was thinking that this would be a neat thing to add. I could have some higher resolution video modes without needing VESA (and VM86). The VESA code is very small, and you want VM86 anyway (amongst other things, for reliable memory detection) But you make a good point in that anyone who wants graphics uses X. I guess I was thinking that maybe the additional modes would be of use should FreeBSD ever really get an equivalent to libsvga. We already have that (libvgl), though it's in deperate need of maintenance. Anyway, as you point out, then the modes are really only of use to splash screens (which is a minor feature in and of itself). So the question becomes, is there any interest in adding 6 mode tweaked modes (in addition to the existing 320x240) or should we reduce complexity and remove the 320x240 mode because surely nothing can be using it (you can only write to every 4th pixel right now). I vote for the latter. OBTW, Mode Q has square pixels and linear addressing. I won't mind adding support for Mode Q :) Mode Q? I'm not familiar with that one. Presumably a less-than-320x200 resolution? No, actually it has 1536 more pixels :) Mode Q is so named because the frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) If you have time and talent to spare and want to work on the console code, I have two suggestions for useful additions: - modify syscons so userland software can mmap the frame buffer, and whatever other modifications are necessary to make it possible for userland software to use graphics without needing write access to /dev/kmem (currently, the only way to mmap the frame buffer is to map in the correct address range from /dev/kmem) Kazu finishing his fb(4) would be quite nice, if he has the time. - port GGI to FreeBSD. Huh? It works for me... GGI is just the API/wrapper, and it allows output to (most useful now) X and XF86DGA (many, many more of course,, and a FreeBSD fb(4) would be cool.). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Feldman_ __ ___ ___ ___ ___ gr...@unixhelp.org_ __ ___ | _ ) __| \ FreeBSD: The Power to Serve! _ __ | _ \ _ \ |) | http://www.freebsd.org _ |___)___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 1GB, kvm issues.
It's been noted on several occasions that with large ( 256MB) of RAM, one has to be careful with the configuration (NMBCLUSTERS, MAXUSERS) to prevent the box from falling over every few days due to kvm problems. Can somebody be more specific? I'm just about to order a really, really expensive machine and I want to be sure I can get it to work .. :) Chuck Youse This was fixed somewhere in the 3.1-STABLE branch, you will not need to worry about this at all with 3.2-BETA/3.2-RELEASE. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
Kelly Yancey kby...@alcnet.com writes: On 14 May 1999, Dag-Erling Smorgrav wrote: No, actually it has 1536 more pixels :) Mode Q is so named because the frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) Yeah, I've seen the DOS port of snes9x use that. I don't think it has truely square pixels though since the screen has a 4:3 aspect ratio and the resolution is 1:1...the pixels should look slightly wider than they are tall. Most monitors display Mode Q with wide black margins. But it is linear :) The question is...is it worth including? I just did a quick search on the net and found the register programming information for this one (256x256x256) and another interesting linear mode (296x220x256) which has almost square pixels and a slightly higher resolution. Umm, no, 296x220 is smaller than 256x256. And if the verdict is that the extra video modes (so long as they are planar) are useful, then how about some tweaked text modes? We have support for a number of different rows, but I have some old patches (which need updating) for extending the number of text mode columns from 80 to 90. Yah. If you can make it work, I'm all for it. - port GGI to FreeBSD. I thought this had been discussed and shot down? If it has, I didn't see it :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 1GB, kvm issues.
Chuck Youse cyo...@cybersites.com writes: It's been noted on several occasions that with large ( 256MB) of RAM, one has to be careful with the configuration (NMBCLUSTERS, MAXUSERS) to prevent the box from falling over every few days due to kvm problems. It's not a problem as long as your kernel address space is large enough. The default in -CURRENT and recent versions -STABLE is 1 GB, which should be enough for most (if not all) uses. The default for 3.1-RELEASE and -STABLE up to mid-April is 256 MB. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
On 14 May 1999, Dag-Erling Smorgrav wrote: Kelly Yancey kby...@alcnet.com writes: On 14 May 1999, Dag-Erling Smorgrav wrote: No, actually it has 1536 more pixels :) Mode Q is so named because the frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) Yeah, I've seen the DOS port of snes9x use that. I don't think it has truely square pixels though since the screen has a 4:3 aspect ratio and the resolution is 1:1...the pixels should look slightly wider than they are tall. Most monitors display Mode Q with wide black margins. But it is linear :) The question is...is it worth including? I just did a quick search on the net and found the register programming information for this one (256x256x256) and another interesting linear mode (296x220x256) which has almost square pixels and a slightly higher resolution. Umm, no, 296x220 is smaller than 256x256. My bad...416 pixels smaller And if the verdict is that the extra video modes (so long as they are planar) are useful, then how about some tweaked text modes? We have support for a number of different rows, but I have some old patches (which need updating) for extending the number of text mode columns from 80 to 90. Yah. If you can make it work, I'm all for it. I used to use it myself on 2.2.7 and 2.2.8. I actually had submitted a PR way back when with the patches (PR/7510). They definately work...unfortunatly syscons has changed a bit since then so I'll have to whip up a new set of patches. BTW, the URL listed in that PR no longer has the old patches, someone can just close it (it's way out of date now anyway). Kelly Yancey ~kby...@alcnet.com~ FreeBSD - The Power To Serve - http://www.freebsd.org/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
dlopen failure
I have a program that is dumping core. --- Here's the gdb output; Program terminated with signal 6, Abort trap. #0 0x800b728 in _kill () (gdb) bt #0 0x800b728 in _kill () #1 0x800b34c in abort () #2 0x8004aa2 in __assert () #3 0x8003b4b in map_object () #4 0x8002e9e in find_symdef () #5 0x800334d in dlopen () #6 0x8049a68 in Get_SQL_Driver (name=0x804c7e4 mysql) at Vdb.c:150 #7 0x8049ff9 in GetDefaultDriver () at Vdb.c:254 #8 0x804a141 in VdbInit (user=0x804bfb1 nobody, passwd=0x0) at Vdb.c:329 #9 0x8049316 in main () #10 0x8048be5 in _start () - here's the output in the logfile identifying the assert failure; May 14 16:11:26 venus qmail: 926694686.764722 delivery 21: deferral: assertion_u.hdr.e_phentsize_==_sizeof(Elf_Phdr)_failed:_file_/usr/src/libexec/rtld-elf/map_object.c,_line_118/Abort_trap_-_core_dumped/ May 14 16:11:26 venus qmail: 926694686.764952 status: local 4/10 remote 0/20 - here's my system; FreeBSD venus.cablenet.net 3.1-RELEASE FreeBSD 3.1-RELEASE #1: Tue Apr 27 11:44:21 BST 1999 r...@server.cablenet.net:/usr/src/sys/compile/SERVER i386 and # cat /etc/objformat OBJFORMAT=elf - and here's the ld line for the shared object I am loading; ld -Bshareable -o $@ $ -u _floor ../../lib/libV.a /usr/local/lib/mysql/libmysqlclient.a /usr/lib/libm.a --- Does anyone know why I am getting this error ? MTIA regards damian *Damian Hamill M.D. dam...@cablenet.net * CableNet The Landscape Channel * http://www.cablenet.net/ http://www.landscapetv.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 1GB, kvm issues.
On Fri, 14 May 1999, David E. Cross wrote: It's been noted on several occasions that with large ( 256MB) of RAM, one has to be careful with the configuration (NMBCLUSTERS, MAXUSERS) to prevent the box from falling over every few days due to kvm problems. Can somebody be more specific? I'm just about to order a really, really expensive machine and I want to be sure I can get it to work .. :) Chuck Youse This was fixed somewhere in the 3.1-STABLE branch, you will not need to worry about this at all with 3.2-BETA/3.2-RELEASE. I thought so as well, however I added a 64 meg dimm and ran into the same problems he is describing. After I remembered the problem. I lowered the value of maxusers and everything is back to normal. This is on 4.0 - Current. btw.. 1 - 128 meg dimm 1 - 64 meg dimm and for the record 750 meg of swap space rob To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 1GB, kvm issues.
has to be careful with the configuration (NMBCLUSTERS, MAXUSERS) to prevent the box from falling over every few days due to kvm problems. Can somebody be more specific? I'm just about to order a really, really expensive machine and I want to be sure I can get it to work .. :) Chuck Youse This was fixed somewhere in the 3.1-STABLE branch, you will not need to worry about this at all with 3.2-BETA/3.2-RELEASE. I thought so as well, however I added a 64 meg dimm and ran into the same problems he is describing. After I remembered the problem. I lowered the value of maxusers and everything is back to normal. This is on 4.0 - Current. btw.. 1 - 128 meg dimm 1 - 64 meg dimm and for the record 750 meg of swap space Well, this is my current config: Dual P2-400, 256M RAM, 256M SWAP, 3.2-BETA, maxusers 256. I have yet to have any wierdness. Note we also run servers based off of the late 3.1-STABLE branch and we *used* to see KVA problems all of the time. For awhile we rolled in the KVA patches by hand, but since the change was MFCed we have not done that and have made 0 patches and everything continues to work great. I am 99.% positive that the changes were made to -current (I know I saw the CVS logs go through on our mirror) I am also 99.99% sur -STABLE is patched too... If not we should really take care of that now. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 1GB, kvm issues.
On Fri, May 14, 1999 at 11:55:49AM -0400, David E. Cross wrote: Well, this is my current config: Dual P2-400, 256M RAM, 256M SWAP, 3.2-BETA, maxusers 256. I have yet to have any wierdness. Note we also run servers based off of the late 3.1-STABLE branch and we *used* to see KVA problems all of the time. For awhile we rolled in the KVA patches by hand, but since the change was MFCed we have not done that and have made 0 patches and everything continues to work great. I am 99.% positive that the changes were made to -current (I know I saw the CVS logs go through on our mirror) I am also 99.99% sur -STABLE is patched too... If not we should really take care of that now. Then add my 0.0001% ;-) dg 1999/03/11 10:28:47 PST Modified files: sys/i386/confMakefile.i386 kernel.script sys/i386/include pmap.h Log: Increased kernel virtual address space to 1GB. NOTE: You MUST have fixed bootblocks in order to boot the kernel after this! Also note that this change breaks BSDI BSD/OS compatibility. Also increased default NKPT to 17 so that FreeBSD can boot on machines with =2GB of RAM. Booting on machines with exactly 4GB requires other patches, not included. Revision ChangesPath 1.141 +2 -2 src/sys/i386/conf/Makefile.i386 1.2 +1 -1 src/sys/i386/conf/kernel.script 1.59 +4 -4 src/sys/i386/include/pmap.h des 1999/04/25 05:44:06 PDT Modified files:(Branch: RELENG_3) sys/i386/confMakefile.i386 kernel.script sys/i386/include pmap.h Log: MFC: increase kvm size to 1 GB. Revision ChangesPath 1.136.2.5 +2 -2 src/sys/i386/conf/Makefile.i386 1.1.2.1 +1 -1 src/sys/i386/conf/kernel.script 1.57.2.1 +3 -3 src/sys/i386/include/pmap.h Cheers, -- Ruslan Ermilov Sysadmin and DBA of the r...@ucb.crimea.ua United Commercial Bank +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ifconfig: changing mac address
Hi guys, Does anyone know... Is it possible to change the mac address of an ethernet card using ifconfig? Does this depend upon the ioctls supported by the specific driver? Thanks. Steve To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: MB86950 Support in the works?
Kris Kirby k...@airnet.net writes: I was wondering if any adventurous individual has looked into writing a driver for the MB86950 ethernet controller. I have quite a few cards that use this chip and would be more than willing to acid-test the driver. (Ever got 1MB/s over coax? :-)) Yes, I've experienced sustained transfer rates in excess of 1 MBps on a 10Base2 network, with FreeBSD 3.1 using an SMC based Kingston EtherX (ISA PnP NE2000 clone thingamabob) in one end and a nondescript Linux box in the other end. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: dlopen failure
- and here's the ld line for the shared object I am loading; ld -Bshareable -o $@ $ -u _floor ../../lib/libV.a /usr/local/lib/mysql/libmysqlclient.a /usr/lib/libm.a This is probably unrelated to the bug (but it might be related). Are the object files libV.a and libmsqlclient.a compiled -fPIC? I know libm.a isn't, so the library work as a shared library. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
Is it possible to change the mac address of an ethernet card using ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
To summarize, it seems like a lot of trouble just to get 40 additional scanlines and square pixels on obsolete hardware - anything that doesn't support 'options VESA' was already obsolete five years ago. Unfortunately, it's the trend these days to _not_ support anything at all interesting in your VESA extensions. See eg. the nVidia Riva TNT firmware. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
Is it possible to change the mac address of an ethernet card using ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. while ifconfig might miss this functionality, i believe your answer is incorrect. Several FreeBSD drivers read the MAC address from the rom/eeprom, copy it to sc-arpcom.ac_enaddr, and write it back to the card's address filter in the init phase. I suppose on other systems the same thing happens. It's a software thing, not a hardware one. A quick check shows the following drivers do that: sys/i386/isa/if_ed.c sys/pci/if_fxp.c sys/pci/if_de.c (probably) just to name the most common ones. cheers luigi ---+- Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: large master.passwd
:Hi : :On a site with 20k users in the master.passwd, and where NIS is not :trusted, the master.passwd is distributed to each workstation. :The pwd.db and spwd.db are sized around 10Mb. : :Sometimes, those .db files get corrupt. :I suspect it has something to do with the machines being reset etc before :the sync is finished. (The machines are dual-boot, and there are a lot of :users around.) : :I did some patching, and have not seen corrupted .db-files since. : :So how usable is this patch? :Worth intregrating? What version of FreeBSD are you running? mmap is used heavily with the password DBM's and at least one mmap bug known to cause corruption in those files was fixed a month or two ago. I do not remember whether it was backported to 2.2.x, though. -Matt :Regards, :Roar Thronæs To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
Some day I will most likely need to deal with this for the Token-ring drivers. In token-ring having a UAA and LAA (Universally/Locally Administered Address) is very common especially in high-availibility situations. Larry Lile l...@stdio.com On Fri, 14 May 1999, Luigi Rizzo wrote: Is it possible to change the mac address of an ethernet card using ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. while ifconfig might miss this functionality, i believe your answer is incorrect. Several FreeBSD drivers read the MAC address from the rom/eeprom, copy it to sc-arpcom.ac_enaddr, and write it back to the card's address filter in the init phase. I suppose on other systems the same thing happens. It's a software thing, not a hardware one. A quick check shows the following drivers do that: sys/i386/isa/if_ed.c sys/pci/if_fxp.c sys/pci/if_de.c (probably) just to name the most common ones. cheers luigi ---+- Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. while ifconfig might miss this functionality, i believe your answer is incorrect. Yep. It's the other way around - any card will allow you to do this, AFAIK. Otherwise they couldn't be made to work with DECnet, for instance. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
Is it possible to change the mac address of an ethernet card using ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. Yeah, we've got some Dy-4 m68k-based single board computers that allow the lower 3 bytes of the MAC address to be programmed. It's kind of annoying though, because the lower 3 bytes are always set to 0 and we have to uniquely set them for each board that we deliver to our customer. The MAC addresses were meant to be unique; why do you want the ability to change them? So you can make M$ viruses without anyone figuring it out who made them ;-)? Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
what happened to that m68k port?
Just out of curiousity, what ever happened with the port that was brought up on -questions? Was it a joke? -Alfred To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
It seems Mike Smith wrote: To summarize, it seems like a lot of trouble just to get 40 additional scanlines and square pixels on obsolete hardware - anything that doesn't support 'options VESA' was already obsolete five years ago. Unfortunately, it's the trend these days to _not_ support anything at all interesting in your VESA extensions. See eg. the nVidia Riva TNT firmware. Endeed, they are going new ways allready, VESA support is an endangered animal half dead allready. We have to face it, the only way to use modern video HW is to have a driver that understands it. That is the exact problem, and why I'm very happy for the work the Xfree86 guys are doing. You can do mode-crap-of-the-day on some oldish and som newish HW, but whats the point ?? If you need a wierd resolution for a game or such, have the game set up the VGA regs, and be with it. Using graphics for much else is just retro-computing coming true :) (said the man that did our current video driver, and lots of graphics utils for it, including the minmalistic libvgl, and loved it). -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
One of the purposes of changing the MAC address is for server redundancy. Suppose that one of your important servers went down. Wouldn't it be nice for the alternative server (a mirror) to get the important server's MAC address (and IP address(es), and AppleTalk address, etc.), so the client's ARP caches don't have to timeout before they can access the important server again (aka the mirror)? -Mark Taylor NetMAX Developer mtay...@cybernet.com On 14-May-99 Daniel Eischen wrote: Is it possible to change the mac address of an ethernet card using ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. Yeah, we've got some Dy-4 m68k-based single board computers that allow the lower 3 bytes of the MAC address to be programmed. It's kind of annoying though, because the lower 3 bytes are always set to 0 and we have to uniquely set them for each board that we deliver to our customer. The MAC addresses were meant to be unique; why do you want the ability to change them? So you can make M$ viruses without anyone figuring it out who made them ;-)? Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
One of the purposes of changing the MAC address is for server redundancy. Suppose that one of your important servers went down. Wouldn't it be nice for the alternative server (a mirror) to get the important server's MAC address (and IP address(es), and AppleTalk address, etc.), so the client's ARP caches don't have to timeout before they can access the important server again (aka the mirror)? Ahhh... Dan Eischen eisc...@vigrid.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Seti project / stats reset, new version available
For people who have idle cpu to spare, this is a good time to start putting those cycles to good use with the Seti project! The project has been running a beta test for a while, but as of May 13th 1999 they reset the stats and introduced new clients for Unix, Windows, and the Mac. I recommend that FreeBSDrs download the FreeBSD3.1 client, even if you are running 4.x, so our stats do not split up. If you are already running the seti client, you need to download a new rev! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
For people who have idle cpu to spare, this is a good time to start putting those cycles to good use with the Seti project! Where would would find informatio on said project? Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
: : For people who have idle cpu to spare, this is a good time to start : putting those cycles to good use with the Seti project! : :Where would would find informatio on said project? : : :Nate Oops! I'm sorry! http://setiathome.ssl.berkeley.edu/ -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
: For people who have idle cpu to spare, this is a good time to start : putting those cycles to good use with the Seti project! : :Where would would find informatio on said project? : : :Nate Oops! I'm sorry! http://setiathome.ssl.berkeley.edu/ They're not responding at the moment (page OK, application server down) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ m...@smith.net.au \\ The race is long, and in the \\ msm...@freebsd.org \\ end it's only with yourself. \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD, GPL, the world today.
On Thu, 13 May 1999 10:25:21 -0400, Dennis den...@etinc.com said: Dennis All software has bugs TeX has no bugs. But it's the exception, not the rule. -- Matt Curtin cmcur...@interhack.net http://www.interhack.net/people/cmcurtin/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD, GPL, the world today.
Matt Curtin wrote: On Thu, 13 May 1999 10:25:21 -0400, Dennis den...@etinc.com said: Dennis All software has bugs TeX has no bugs. TeX has no *known* bugs. To the best of my knowlege, even Dr. Knuth has not yet been able to *prove* it is correct. But it's the exception, not the rule. It certainly is, but perhaps it shouldn't be. I've worked on a few carefully verified systems, and they are quite expensived to create. They're the kind of systems that you hope would be carefully checked, though, since they involve flinging nuclear bombs at people. Anyone want to pony up a few dozen million dollars to do an NSCCA on FreeBSD? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD, GPL, the world today.
+[ Matt Curtin ]- | On Thu, 13 May 1999 10:25:21 -0400, Dennis den...@etinc.com said: | | Dennis All software has bugs | | TeX has no bugs. | | But it's the exception, not the rule. You cannot test for the abscence of bugs. -- Totally Holistic Enterprises Internet| P:+61 7 3870 0066 | Andrew The Internet (Aust) Pty Ltd | F:+61 7 3870 4477 | Milton ACN: 082 081 472 | M:+61 416 022 411 |72 Col .Sig PO Box 837 Indooroopilly QLD 4068|a...@theinternet.com.au|Specialist To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
: : For people who have idle cpu to spare, this is a good time to start : putting those cycles to good use with the Seti project! : :Where would would find informatio on said project? : : :Nate Oops! I'm sorry! http://setiathome.ssl.berkeley.edu/ Now available at ftp://ftp.cdrom.com/pub/setiathome/ -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
:http://setiathome.ssl.berkeley.edu/ : : Now available at ftp://ftp.cdrom.com/pub/setiathome/ : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com Yah, but I spoke too soon.. their 1.1 client is coughing chunks. It's seriously broken. Growl. How annoying, I hope they fix it ASAP! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Seti project / stats reset, new version available
So do I. I would like them to make the source available. I have *lots* of machines available that are sitting doing nothing. But they don't run FreeBSD (yet). I have at least 3 alpha 8200s and 4 Alpha 4100s that are running NetBSD now and mostly quiescent. On Fri, 14 May 1999, Matthew Dillon wrote: :http://setiathome.ssl.berkeley.edu/ : : Now available at ftp://ftp.cdrom.com/pub/setiathome/ : :-DG : :David Greenman :Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org :Creator of high-performance Internet servers - http://www.terasolutions.com Yah, but I spoke too soon.. their 1.1 client is coughing chunks. It's seriously broken. Growl. How annoying, I hope they fix it ASAP! -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Native Applixware for FreeBSD -- When?
On Thu, May 13, 1999 at 08:07:41PM -0400, Chuck Robey wrote: On Thu, 13 May 1999, Nik Clayton wrote: Your XML aware web browser could then also read in these ATLL files and do something useful with them too, *without you needing to convert them to HTML first*. This is where the XML Style Language (XSL) comes in. XML is really SGML-lite. Most of chapter 3 of http://www.freebsd.org/tutorials/docproj-primer/ is accurate for XML as well. Except that XSL is not the XML Style Language. Argh. That's what I get for trying to be quick :-) Look at the FDP Primer, that was only meant to be ~ 5 pages when I started writing the damn thing. snip There are a lot of free tools using xml and xsl out there. Indeed. Anyone interested in persuing this is recommended to head on over to -doc, and/or take a look at http://www.oasis-open.org/cover/ N -- There's some milk in the fridge about to go off. . . and there it goes. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
[Apologies if this is duplicated, sort of; I inadvertently lost power as I was sending a reply to this, and I don't have a record that it was sent]. From: Nate Williams n...@mt.sri.com Date: 1999-05-14 10:11:52 -0700 To: steve.gai...@db.com Subject: Re: ifconfig: changing mac address Cc: freebsd-hackers@FreeBSD.ORG In-reply-to: 199905141618.raa03...@pow.srv.uk.deuba.com Delivered-to: freebsd-hackers@freebsd.org X-Mailer: VM 6.34 under 19.16 Lille XEmacs Lucid X-Loop: FreeBSD.ORG Is it possible to change the mac address of an ethernet card using ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. I don't believe this is correct. The cards I'm familiar with only accept unicast packets when programmed with a specific MAC address. This is normally the one that's in a ROM associated with the device somehow, but there's no reason it can't be changed. DECNet, for example, assumes for some protocols at least, that the MAC address is one from the block of addresses owned by DEC. CompaqNet? Sheesh. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics | Manager, CoreOS Networking| When crypto is outlawed, Apple Computer, Inc. | Only outlaws will have crypto. 2 Infinite Loop | Cupertino, CA 95014 | *-*---* To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Friday, 14 May 1999 at 15:43:15 -0400, Mark J. Taylor wrote: On 14-May-99 Daniel Eischen wrote: Is it possible to change the mac address of an ethernet card using ifconfig? Not in any 'standard' card, no. Some cards (in SUN workstations) allow you to swap the EEPROM with the mac address, and I'll bet somewhere someone has designed a card with a programmable mac address, but normally it's not settable. Yeah, we've got some Dy-4 m68k-based single board computers that allow the lower 3 bytes of the MAC address to be programmed. It's kind of annoying though, because the lower 3 bytes are always set to 0 and we have to uniquely set them for each board that we deliver to our customer. The MAC addresses were meant to be unique; why do you want the ability to change them? So you can make M$ viruses without anyone figuring it out who made them ;-)? One of the purposes of changing the MAC address is for server redundancy. Yes, and in fact Tandem^H^H^H^H^H^HCompaq use this for their NonStop Ethernet. The machine has two ethernet boards. If one goes down, the other assumes its identity. It seems there's a need, and the possibility. Would somebody like to suggest a syntax? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Sat, 15 May 1999, Greg Lehey wrote: : :It seems there's a need, and the possibility. Would somebody like to :suggest a syntax? : ifconfig interface ether ab:cd:ef:fe:dc:ab [options] makes sense to me. David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
In the last episode (May 14), David Scheidt said: On Sat, 15 May 1999, Greg Lehey wrote: :It seems there's a need, and the possibility. Would somebody like :to suggest a syntax? ifconfig interface ether ab:cd:ef:fe:dc:ab [options] makes sense to me. And the next step would be to make the kernel realize that two cards ifconfig'd with the same MAC address are meant to be bonded together as one route (lots of switches support this). I have some machines that I'd love to be able to get 20MB/sec bandwidth between transparently. -Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Friday, 14 May 1999 at 21:15:33 -0500, Dan Nelson wrote: In the last episode (May 14), David Scheidt said: On Sat, 15 May 1999, Greg Lehey wrote: :It seems there's a need, and the possibility. Would somebody like :to suggest a syntax? ifconfig interface ether ab:cd:ef:fe:dc:ab [options] makes sense to me. And the next step would be to make the kernel realize that two cards ifconfig'd with the same MAC address are meant to be bonded together as one route (lots of switches support this). I have some machines that I'd love to be able to get 20MB/sec bandwidth between transparently. I think you need to reconsider that idea. How are you going to double the bandwidth of the wire? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Sat, 15 May 1999, Greg Lehey wrote: :On Friday, 14 May 1999 at 21:15:33 -0500, Dan Nelson wrote: : : And the next step would be to make the kernel realize that two cards : ifconfig'd with the same MAC address are meant to be bonded together as : one route (lots of switches support this). I have some machines that : I'd love to be able to get 20MB/sec bandwidth between transparently. : :I think you need to reconsider that idea. How are you going to double :the bandwidth of the wire? : I think he means having two interfaces in each box, with the same MAC. So he has two wires, each with 10Mbs. David Scheidt To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
In the last episode (May 15), Greg Lehey said: And the next step would be to make the kernel realize that two cards ifconfig'd with the same MAC address are meant to be bonded together as one route (lots of switches support this). I have some machines that I'd love to be able to get 20MB/sec bandwidth between transparently. I think you need to reconsider that idea. How are you going to double the bandwidth of the wire? Two wires :) Drop two Intel EtherExpress 10/100 NICs into a Netware box, load the Intel failover/bonding .NLM, plug the NICs into adjacent ports on a compatible switch (we use BayStacks), configure the switch to bond those two ports together, and you instantly double your bandwidth. If a card fails, all traffic simply routes to the other card. I've only been able to max out both cards once (according to my mrtg graph), but it does work. It shouldn't be strictly limited to EtherExpress cards though. The general idea should work no matter what cards you have. -Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Friday, 14 May 1999 at 21:41:23 -0500, David Scheidt wrote: On Sat, 15 May 1999, Greg Lehey wrote: :On Friday, 14 May 1999 at 21:15:33 -0500, Dan Nelson wrote: : : And the next step would be to make the kernel realize that two cards : ifconfig'd with the same MAC address are meant to be bonded together as : one route (lots of switches support this). I have some machines that : I'd love to be able to get 20MB/sec bandwidth between transparently. : :I think you need to reconsider that idea. How are you going to double :the bandwidth of the wire? : I think he means having two interfaces in each box, with the same MAC. So he has two wires, each with 10Mbs. If you have two different nets, why do you need the same Ethernet address? Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Sat, 15 May 1999, Greg Lehey wrote: : :If you have two different nets, why do you need the same Ethernet :address? : Transparent redundancy. With them both up on the same MAC address, if one fails, you have no loss of connection, though you may drop some packets, of course. Most of the time you get twice the bandwidth. David, who doesn't want to think about writing a driver for this. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Friday, 14 May 1999 at 21:54:02 -0500, David Scheidt wrote: On Sat, 15 May 1999, Greg Lehey wrote: : :If you have two different nets, why do you need the same Ethernet :address? : Transparent redundancy. With them both up on the same MAC address, if one fails, you have no loss of connection, though you may drop some packets, of course. Most of the time you get twice the bandwidth. David, who doesn't want to think about writing a driver for this. OK, now maybe I'm missing something here. But an Ethernet address is used to identify a board. Arp binds it to an IP address. An IP address is bound to a network. So if you're on a different network, you get a different IP address. Why do you need the same Ethernet address? This is very different from having two boards on the same network, both with the same Ethernet address. As I observed earlier, that does make sense, but it's a hot standby situation. I can't see any point in arranging for both of them to accept or send data. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
On Sat, 15 May 1999, Greg Lehey wrote: :OK, now maybe I'm missing something here. But an Ethernet address is :used to identify a board. Arp binds it to an IP address. An IP :address is bound to a network. So if you're on a different network, :you get a different IP address. Why do you need the same Ethernet :address? You need a switch to do this. If your clients are on the same ethernet as your server, they can only talk to one MAC address. That means you only get the bandwidth of one interface. If you have a switch that can bond ports together, you can use both cards at the same time, transparently to everybody but the driver and the switch. I know that NetWare supports this, as do some Bay switch, and surely some Cisco stuff. David To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
You need a switch to do this. If your clients are on the same ethernet as your server, they can only talk to one MAC address. That means you only get the bandwidth of one interface. If you have a switch that can bond ports together, you can use both cards at the same time, transparently to everybody but the driver and the switch. I know that NetWare supports this, as do some Bay switch, and surely some Cisco stuff. Having 2 ethernet cards with the same mac address on two different ports of all the cisco switches I have used (1100-6500) will confuse the hell out of them :). I've seen it happen. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
In the last episode (May 15), Greg Lehey said: OK, now maybe I'm missing something here. But an Ethernet address is used to identify a board. Arp binds it to an IP address. An IP address is bound to a network. So if you're on a different network, you get a different IP address. Why do you need the same Ethernet address? I don't think anyone mentioned anything about having the cards on two networks. In that case, you're right, having two cards with the same MAC address doesn't help one bit. This is very different from having two boards on the same network, both with the same Ethernet address. As I observed earlier, that does make sense, but it's a hot standby situation. I can't see any point in arranging for both of them to accept or send data. Doubles the bandwidth. Especially if you are talking to multiple machines (i.e. talk to two regular boxes at 100mbit/sec each), or have another box hooked up the same way (200mbit/sec to it). Since both cards in the server have the same MAC address, the client boxes don't know anything's unusual. -Dan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
You have to have the capibility on the switch, and enable it first. It is called EtherChannel by Cisco, and it is 2 or 4 ports that all have the same MAC addr plugged into the switch, and the switch treats them as one interface. --John Steve Rubin s...@tch.org wrote: You need a switch to do this. If your clients are on the same ethernet as your server, they can only talk to one MAC address. That means you only ge t the bandwidth of one interface. If you have a switch that can bond ports together, you can use both cards at the same time, transparently to everybo dy but the driver and the switch. I know that NetWare supports this, as do so me Bay switch, and surely some Cisco stuff. Having 2 ethernet cards with the same mac address on two different ports of all the cisco switches I have used (1100-6500) will confuse the hell out of them :). I've seen it happen. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
Greg Lehey wrote: On Friday, 14 May 1999 at 15:43:15 -0400, Mark J. Taylor wrote: One of the purposes of changing the MAC address is for server redundancy. Yes, and in fact Tandem^H^H^H^H^H^HCompaq use this for their NonStop Ethernet. The machine has two ethernet boards. If one goes down, the other assumes its identity. It seems there's a need, and the possibility. Would somebody like to suggest a syntax? Be sure to account for canonical vs. non-canonical representations for Token Ring while you're at it. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
Greg Lehey wrote: OK, now maybe I'm missing something here. But an Ethernet address is used to identify a board. Arp binds it to an IP address. An IP address is bound to a network. So if you're on a different network, you get a different IP address. Why do you need the same Ethernet address? This is very different from having two boards on the same network, both with the same Ethernet address. As I observed earlier, that does make sense, but it's a hot standby situation. I can't see any point in arranging for both of them to accept or send data. Redundancy and throughput both. Most switches can do this; using two physical ports as one logical link. Think of it as network link striping. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ifconfig: changing mac address
David Scheidt wrote: On Sat, 15 May 1999, Greg Lehey wrote: :OK, now maybe I'm missing something here. But an Ethernet address is :used to identify a board. Arp binds it to an IP address. An IP :address is bound to a network. So if you're on a different network, :you get a different IP address. Why do you need the same Ethernet :address? You need a switch to do this. If your clients are on the same ethernet as your server, they can only talk to one MAC address. That means you only get the bandwidth of one interface. If you have a switch that can bond ports together, you can use both cards at the same time, transparently to everybody but the driver and the switch. I know that NetWare supports this, as do some Bay switch, and surely some Cisco stuff. And all Xylan switches (soon, if not now.) ;^) -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://www.softweyr.com/~softweyr w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
