Re: Tiny BSD Pages
Hi, Juli Mallett schrieb: * De: Michael Bretterklieber [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Tiny BSD Pages ] Hi, Chris Fowler schrieb: I do one thing in Linux that I want to do in FreeBSD. I store my root file system as a blow fish, gzipped, encrypted file on a DiskOnChip. I have done exactly this some years ago, checkout PicoBSD (freebsd-small mailinglist). But I don't know the current status of PicoBSD. see also: http://people.freebsd.org/~picobsd/ With a lot of work it builds again, but due to hardware issues, I don't know if it worked :) good to hear that someone actively maintains PicoBSD. however, atm we are using FreeBSD with ro-mounts on normal Harddisks. Wich has nearly the same effect as PicoBSD, e.g. powering off without any data loss, or fsck on reboot, but it has more flexibility because you can use the ports for installing software. bye, -- --- -- Michael Bretterklieber - [EMAIL PROTECTED] JAWA Management Software GmbH - http://www.jawa.at Liebenauer Hauptstr. 200-- privat A-8041 GRAZ GSM: ++43-(0)676-84 03 15 712 Tel: ++43-(0)316-403274-12 E-mail: [EMAIL PROTECTED] Fax: ++43-(0)316-403274-10 http://www.bretterklieber.com --- -- ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
Yeah, it kinda sucks but I'm not sure how it works... when are the mbufs freed? If they're all freed in a continous for loop that kinda sucks. I think there is nothing really special about the driver there? The mbufs are allocated in the driver and then freed when other parts in the kernel are done with the packet? The issue I´m having is that mb_free takes almost four times the cycles than mb_alloc for each call which does not seem to be right? I shouldn´t be having lock contention in mb_alloc because the whole thing is still under Giant, right? Nothing seems to be moving to the GEN pool. Lower the high watermark to like 512... wait for the next free... if it's still not moving, but you see that the per-cpu caches are being used (in use is changing), please let me know ASAP. It´s moving, however no change in performance. In use hovers around 7000 for mbufs and clusters alike. Now the only difference is that in pool also changes constantly because mbufs are shuffled between pools. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mbuf cache
While you are there debugging mbuf issues, you might also want to try this patch: Didn´t run profiling yet, but judging from the CPU utilization, this did not change the whole picture a lot (dunno why it should since CPU is mostly spent freeing the mbufs, not allocating them) Pete Oops, my first patch had some bugs because of quick editing. Please try the newer patch: http://www.unixdaemons.com/~hiten/work/mbuf/if_em.c.patch Cheers. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Hi, Here's a hint: The Apollo Domain and XNS networking protocols will no longer be offered after Cisco IOS Release 12.2. Information about these protocols will not appear in future releases of the Cisco IOS software documentation set. http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a008007fba7.html He's dead, Jim. -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Bob Bishop wrote: Here's a hint: The Apollo Domain and XNS networking protocols will no longer be offered after Cisco IOS Release 12.2. Information about these protocols will not appear in future releases of the Cisco IOS software documentation set. http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a008007fba7.html He's dead, Jim. The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. Given that the current TCP/IP stack no longer matches the Stevens books, and given that Stevens is too dead to update the books to the new FreeBSD stack, even if he wanted to, it's useful to have a relatively simple set of code that can be understood without a book that's not getting written. Also, it's interesting from the perspective of people with living Xerox Alto hardware (not many, but they do exist), but I fully admit that that's not a compelling reason. On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. In any case, Peter pointed out that my patch was against -stable, not -current. I'm in the process of CVSup'ing new sources now, and will update the patch against -current, and post it, most likely tomorrow morning, if the CVSup doesn't complete in the next hour. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. I have a 486, lots of people have 486 PC 104 boards. I have a lot of ISA stuff. VLSI support would be equally obsolete. So would support for a Sequent SMP 386. We don't support them. We have at least one feature you demonstate over and over needs moved to the attic. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: ata_dmasetup: transfer active on this device!
Hello, My laptop freeze *systematically* while resuming from suspend mode (ACPI) with recent (as of yesterday) kernels. I experienced the same problem with old (January 25th) kernels, but only from time to time (once every 3-5 times I would say) PS: there is no disk activity when i suspend the laptop (in the sense of: the disk led is off, and i stop all disk consuming activities). But seeing the panic message, it seems this is not actually true ;-) PPS: my world is not in sync with the new kernel, i'm a bit reluctant to sync with a kernel no more being able to resume. But perhaps this is the root of my problem Anybody else experiencing that ? Here is a backtrace: Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bdwrite: buffer is not busy panic messages: --- panic: ata_dmasetup: transfer active on this device! syncing disks, buffers remaining... panic: bdwrite: buffer is not busy Uptime: 3h16m31s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 #1 0xc02b6222 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xc02b6483 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #3 0xc02fc43d in bdwrite (bp=0xc767d580) at /usr/src/sys/kern/vfs_bio.c:994 #4 0xc03b85e1 in ffs_update (vp=0xc28af920, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_inode.c:125 #5 0xc03cdaef in ffs_fsync (ap=0xcd17dac8) at /usr/src/sys/ufs/ffs/ffs_vnops.c:314 #6 0xc03cca47 in ffs_sync (mp=0xc2731000, waitfor=2, cred=0xc0eb2e80, td=0xc04dd680) at vnode_if.h:612 #7 0xc031269b in sync (td=0xc04dd680, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:138 #8 0xc02b5e0c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280 #9 0xc02b6483 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #10 0xc019c763 in ata_dmastart (atadev=0x0, data=0x0, count=0, dir=0) at /usr/src/sys/dev/ata/ata-dma.c:254 #11 0xc019da21 in ad_transfer (request=0xc265e600) at /usr/src/sys/dev/ata/ata-disk.c:494 #12 0xc018f569 in ata_start (ch=0xc2602300) at /usr/src/sys/dev/ata/ata-all.c:678 #13 0xc019d3b2 in adstrategy (bp=0x0) at /usr/src/sys/dev/ata/ata-disk.c:300 #14 0xc027b0dc in g_disk_start (bp=0xc2a1b000) at /usr/src/sys/geom/geom_disk.c:225 #15 0xc027deb6 in g_io_schedule_down (tp=0xc0ec8000) at /usr/src/sys/geom/geom_io.c:427 #16 0xc027e338 in g_down_procbody () at /usr/src/sys/geom/geom_kern.c:111 #17 0xc02a0fd3 in fork_exit (callout=0xc027e310 g_down_procbody, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:871 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic: ata_dmasetup: transfer active on this device!
A known issue. Soren is working on that. On Wed, Mar 05, 2003 at 10:14:34AM +0100, Yann Berthier wrote: Hello, My laptop freeze *systematically* while resuming from suspend mode (ACPI) with recent (as of yesterday) kernels. I experienced the same problem with old (January 25th) kernels, but only from time to time (once every 3-5 times I would say) PS: there is no disk activity when i suspend the laptop (in the sense of: the disk led is off, and i stop all disk consuming activities). But seeing the panic message, it seems this is not actually true ;-) PPS: my world is not in sync with the new kernel, i'm a bit reluctant to sync with a kernel no more being able to resume. But perhaps this is the root of my problem Anybody else experiencing that ? Here is a backtrace: Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bdwrite: buffer is not busy panic messages: --- panic: ata_dmasetup: transfer active on this device! syncing disks, buffers remaining... panic: bdwrite: buffer is not busy Uptime: 3h16m31s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 #1 0xc02b6222 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0xc02b6483 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #3 0xc02fc43d in bdwrite (bp=0xc767d580) at /usr/src/sys/kern/vfs_bio.c:994 #4 0xc03b85e1 in ffs_update (vp=0xc28af920, waitfor=0) at /usr/src/sys/ufs/ffs/ffs_inode.c:125 #5 0xc03cdaef in ffs_fsync (ap=0xcd17dac8) at /usr/src/sys/ufs/ffs/ffs_vnops.c:314 #6 0xc03cca47 in ffs_sync (mp=0xc2731000, waitfor=2, cred=0xc0eb2e80, td=0xc04dd680) at vnode_if.h:612 #7 0xc031269b in sync (td=0xc04dd680, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:138 #8 0xc02b5e0c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280 #9 0xc02b6483 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 #10 0xc019c763 in ata_dmastart (atadev=0x0, data=0x0, count=0, dir=0) at /usr/src/sys/dev/ata/ata-dma.c:254 #11 0xc019da21 in ad_transfer (request=0xc265e600) at /usr/src/sys/dev/ata/ata-disk.c:494 #12 0xc018f569 in ata_start (ch=0xc2602300) at /usr/src/sys/dev/ata/ata-all.c:678 #13 0xc019d3b2 in adstrategy (bp=0x0) at /usr/src/sys/dev/ata/ata-disk.c:300 #14 0xc027b0dc in g_disk_start (bp=0xc2a1b000) at /usr/src/sys/geom/geom_disk.c:225 #15 0xc027deb6 in g_io_schedule_down (tp=0xc0ec8000) at /usr/src/sys/geom/geom_io.c:427 #16 0xc027e338 in g_down_procbody () at /usr/src/sys/geom/geom_kern.c:111 #17 0xc02a0fd3 in fork_exit (callout=0xc027e310 g_down_procbody, arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:871 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: panic: ata_dmasetup: transfer active on this device!
On Wed, 05 Mar 2003, Ruslan Ermilov wrote: A known issue. Soren is working on that. Ok, I knew in fact that Soren was working on that. What strikes me is that, from what i see, the situation degrades from kernel to kernel. So I posted a backtrace in case of an interaction with other recent commits, beside Soren's work, not yet known But anyway, I will wait patiently until this issue is eradicated :) Thanks, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Plea for base system trim
Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? Now that there is portupgrade it is so much easier to update ports and packages that the make buildworld etc cycle for base system updates seems even more painful. Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. Jim Hatfield To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, 5 Mar 2003, Subscriber wrote: Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? This topic has been discussed ad nauseum, and the consensus has always been that those three things (and openssh) should stay in. Please see the archives for the reasoning. For example, as BIND maintainer I actually _support_ the theory of removing BIND, however the reality is a little different. There are three main components of BIND; the named stuff (sbin/named, sbin/ndc, etc.), the userland stuff (dig, host, etc.), and the resolver library. Of those three things, we actually need the last two in order to include ourselves in a useful definition of Unix system (although I'd LOVE to nuke nslookup, if I thought I could ever live down the whining and crying it would cause). So keeping BIND in the base actually serves a purpose. Similar arguments can be made for the other components you listed. Now that said, I've been working off and on to make it easier to replace parts of the base with stuff from the ports. Both BIND ports have PORT_REPLACES_BASE_ Makefile options, and I know that they are useful because I use them at work. I have a proposal document and some patches that both need polishing to create a standard way to do this. My long term goal (although this is not necessarily shared by other people in the project) is to make it easier to create a modular system that takes advantage of the ports exclusively for contrib code. Of course, we've been talking about this for 8 years too, so don't hold your breath. :) Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. That sounds like a mistake to me, but I'm not familiar with the details. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
D'oh, I forgot the other half of my response (I KNOW you're disappointed by this). :) A big part of the reason that perl was cut is that bmake'ing the build was a NIGHTMARE. By contrast, the BIND bmake glue is not terribly difficult to maintain. The other contributing factors were the license (not BSD friendly, although not as bad as some other things), the fact that we'd already cut other interpreted languages like tcl, and the fact that the perl state of the art moves faster than our major release cycles. Of course, it doesn't help that perl weenies (of which I'm one) tend to like the bleeding edge, and FreeBSD is (rightfully) more of a comfortable, don't upgrade it if it already works kind of place. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
Thus spake Subscriber [EMAIL PROTECTED]: Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? Please don't restart this flamewar. When we have a better installer, then it may be possible in the future to select between multiple mailers (for example), but nobody is going to rip out widely-used functionality because someone has a pet peeve. (And yes, this *is* just a pet peeve; if it were not, you'd see people complaining about ntpd, ipfilter, pnpinfo, etc. instead.) Check the archives. As far as security updates are concerned, keep in mind that base system components are actually *better* supported by the FreeBSD security officer than are ports. If you really want the ports version of something, put the appropriate NO_* option in your make.conf and install the ports version instead. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert [EMAIL PROTECTED] wrote: Given that the current TCP/IP stack no longer matches the Stevens books, and given that Stevens is too dead to update the books to the new FreeBSD stack, even if he wanted to, it's useful to have a relatively simple set of code that can be understood without a book that's not getting written. Actually the Stevens books are still useful as a guide to the FreeBSD IP stack because they give the important overview and description of how the parts fit together. The details might be different but not enough to confuse a competent programmer. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ ROCKALL MALIN HEBRIDES: CYCLONIC BECOMING WEST OR SOUTHWEST 6 TO GALE 8, OCCASIONALLY SEVERE GALE 9 IN MALIN AND HEBRIDES AT FIRST. SQUALLY SHOWERS. GOOD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
pass0: 3224652.361MB/s transfers
can anyone explain why FreeBSD think that my scanner can provide over 3TB/s data rate??? Or it's just a (-1) incorrectly formatted as unsigned on printf() ? boot -v dmesg: Calibrating clock(s) ... TSC clock: 400897760 Hz, i8254 clock: 1193149 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 400911576 Hz CPU: AMD-K6(tm) 3D processor (400.91-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x58c Stepping = 12 Features=0x8021bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,PGE,MMX AMD Features=0x8800SYSCALL,3DNow! found- vendor=0x1022, dev=0x2020, revid=0x10 bus=0, slot=12, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x04 (1000 ns), maxlat=0x28 (1 ns) intpin=a, irq=11 amd0: Tekram DC390(T)/AMD53c974 SCSI Host Adapter port 0xb000-0xb07f irq 11 at device 12.0 on pci0 pass0 at amd0 bus 0 target 1 lun 0 pass0: Color FilmScanner1 0117 Fixed Scanner SCSI-2 device pass0: Serial Number I pass0: 3224652.361MB/s transfers Mounting root from ufs:/dev/ad1s1a Be nice to each other, mmmkay? Yuriy Tsibizov, http://chibis.persons.gfk.ru To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. --- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) --- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. - -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
The beauty of ppp is that you have support in the kernel to do it. Else, you are stuck to writing some type of interface driver for the kernel. In the short term, this may not be a workable solution. On a side note, I read an article on /. about using firewire + MinDV for backup. I guess I can get some use out of my camera after all. Chris On Wed, 2003-03-05 at 09:21, David Leimbach wrote: Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. - -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
mdmfs broken?
Hi, What's the correct syntax in 5-CURRENT to have a memory disk for /tmp in your /etc/fstab? It seems that mdmfs is broken somehow, or else I'm not reading the instructions right: FreeBSD pcwin352.win.tue.nl 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Mar 4 17:32:19 CET 2003 [EMAIL PROTECTED]:/local/freebsd/CURRENT/obj/local/freebsd/CURRENT/src/sys/PCWIN352 i386 Script started on Wed Mar 5 15:22:20 2003 pcwin352# mdmfs md /tmp mdmfs: mdconfig (attach) exited with error code 1 pcwin352# mdmfs md0 /tmp mdmfs: mdconfig (attach) exited with error code 1 pcwin352# mdconfig -a -t swap -s 256M md0 pcwin352# newfs -U md0 /dev/md0: 256.0MB (524288 sectors) block size 16384, fragment size 4096 using 4 cylinder groups of 64.02MB, 4097 blks, 4224 inodes. with soft updates super-block backups (for fsck -b #) at: 32, 131136, 262240, 393344 pcwin352# mount /dev/md0 /tmp pcwin352# chmod 1777 /tmp pcwin352# exit Script done on Wed Mar 5 15:23:03 2003 So by hand it works. Suggestions? --Stijn -- From the moment I picked your book up until I laid it down I was convulsed with laughter. Some day I intend reading it. -- Groucho Marx pgp0.pgp Description: PGP signature
CVSROOT directory gone?
I can't seem to get a mirror copy of the CVSROOT directory with my cvsup script. This worked fine a few days ago. cvsup2.FreeBSD.org is the server I used. Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave On Wednesday, March 5, 2003, at 08:30 AM, Christopher Fowler wrote: The beauty of ppp is that you have support in the kernel to do it. Else, you are stuck to writing some type of interface driver for the kernel. In the short term, this may not be a workable solution. On a side note, I read an article on /. about using firewire + MinDV for backup. I guess I can get some use out of my camera after all. Chris On Wed, 2003-03-05 at 09:21, David Leimbach wrote: Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. --- -- -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) --- -- -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVSROOT directory gone?
The following mail was sent to current@ from Peter Wemm yesterday: snip Anybody who uses the cvs-supfile example to get the repository should add cvsroot-all to their supfile. This is in addition to src-all, ports-all, doc-all etc. This is *ONLY* for the folks getting the CVS ,v files via cvsup. If you use tag=. or tag=RELENG_4, then you are not affected by this. I have updated cvs-supfile in -current but not RELENG_4 yet. Cheers, -Peter /snip /mich David Leimbach (leimy2k) writes: I can't seem to get a mirror copy of the CVSROOT directory with my cvsup script. This worked fine a few days ago. cvsup2.FreeBSD.org is the server I used. Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
Subscriber wrote: Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? There are /etc/make.conf variables to control this so you can do it for yourself: #NO_BIND= true# do not build BIND #NO_OPENSSH=true# do not build OpenSSH #NO_OPENSSL=true# do not build OpenSSL (implies NO_OPENSSH) #NO_SENDMAIL= true# do not build sendmail and related programs Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: IP over IEEE1394?
Wouldn't you need a firewire switch to do a cluster of more than 2 nodes? Or are you thinking of using multiple firewire interfaces per node? -Original Message- From: David Leimbach [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 8:32 AM To: Christopher Fowler Cc: [EMAIL PROTECTED] Subject: Re: IP over IEEE1394? True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re:Witness problem with sound
Yuriy wrote: | Mar 4 14:56:27 port2 kernel:=20 | /usr/src/sys/vm/uma_core.c:1330: could sleep with | pcm0:play:0 locked from /usr/src/sys/dev/sound/pcm/dsp.c:748 | this problem is in last (1.27-1.28) changes in = | /usr/src/sys/dev/sound/pcm/feeder.c (if I remember correctly) | You can revert to previous version (1.27) if you don't want to see = | witness messages. The code just got reverted. Reverting this code is not ideal, but really a more fundamental fix is required and neither state of the feeder files helps. By reverting the code it'll generate less email, and in the meantime we can hopefully sort out a more fundamental fix. Regards - Orion To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert (Wed, Mar 05, 2003 at 04:15:11AM -0800) wrote: Tony Finch wrote: The details might be different but not enough to confuse a competent programmer. Same argument, in favor of the netns code. It's a moot point anyway, I just fixed netns. Sorry to but in, but I don't see why this so called bikesheed keeps getting bigger and bigger. The outcome is simple. If your patches function properly, then there is no need to remove netns provided you don't mind maintaining it. If it doesn't have a maintainer, then just apply your fixes and shuv it in the Attic so it's less horid when someone wants to restart the effort of maintaining it. Not that I can do anything about it, but I can't see why this discussion is getting bigger and bigger for no reason. Cheers. PS. Just my 2 cents. -- Hiten Pandya ([EMAIL PROTECTED], [EMAIL PROTECTED]) http://www.unixdaemons.com/~hiten/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
coda_vnops breaks kernel buil
Two hour old src, when doing a make buildkernel KERNCONF=GENERIC : dfdsf /usr/src/sys/coda/coda_vnops.c:171: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:171: (near initialization for `coda_vnodeop_entries[42]') /usr/src/sys/coda/coda_vnops.c:1984: warning: function declaration isn't a prototype *** Error code 1 More details attached. /mich -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* cc -O -pipe -mcpu=pentiumpro -D_KERNEL -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissin g-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/dev -I@/../include -fno-common -g -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -W cast-qual -fformat-extensions -ansi -c /usr/src/sys/coda/coda_vnops.c /usr/src/sys/coda/coda_vnops.c:142: `coda_pathconf' undeclared here (not in a function) /usr/src/sys/coda/coda_vnops.c:142: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:142: (near initialization for `coda_vnodeop_entries[29].opve_impl') /usr/src/sys/coda/coda_vnops.c:142: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:142: (near initialization for `coda_vnodeop_entries[29]') /usr/src/sys/coda/coda_vnops.c:143: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:143: (near initialization for `coda_vnodeop_entries[30]') /usr/src/sys/coda/coda_vnops.c:144: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:144: (near initialization for `coda_vnodeop_entries[31]') /usr/src/sys/coda/coda_vnops.c:145: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:145: (near initialization for `coda_vnodeop_entries[32]') /usr/src/sys/coda/coda_vnops.c:146: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:146: (near initialization for `coda_vnodeop_entries[33]') /usr/src/sys/coda/coda_vnops.c:147: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:147: (near initialization for `coda_vnodeop_entries[34]') /usr/src/sys/coda/coda_vnops.c:148: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:148: (near initialization for `coda_vnodeop_entries[35]') /usr/src/sys/coda/coda_vnops.c:149: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:149: (near initialization for `coda_vnodeop_entries[36]') /usr/src/sys/coda/coda_vnops.c:150: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:150: (near initialization for `coda_vnodeop_entries[37]') /usr/src/sys/coda/coda_vnops.c:167: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:167: (near initialization for `coda_vnodeop_entries[38]') /usr/src/sys/coda/coda_vnops.c:168: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:168: (near initialization for `coda_vnodeop_entries[39]') /usr/src/sys/coda/coda_vnops.c:169: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:169: (near initialization for `coda_vnodeop_entries[40]') /usr/src/sys/coda/coda_vnops.c:170: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:170: (near initialization for `coda_vnodeop_entries[41]') /usr/src/sys/coda/coda_vnops.c:171: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:171: (near initialization for `coda_vnodeop_entries[42]') /usr/src/sys/coda/coda_vnops.c:1984: warning: function declaration isn't a prototype *** Error code 1 pgp0.pgp Description: PGP signature
Re: coda_vnops breaks kernel buil
Michael Hostbaek (mich) writes: Two hour old src, when doing a make buildkernel KERNCONF=GENERIC : dfdsf /usr/src/sys/coda/coda_vnops.c:171: initializer element is not constant /usr/src/sys/coda/coda_vnops.c:171: (near initialization for `coda_vnodeop_entries[42]') /usr/src/sys/coda/coda_vnops.c:1984: warning: function declaration isn't a prototype *** Error code 1 Hmm.. I'll try and whack my src tree, and cvsup again. /mich -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* pgp0.pgp Description: PGP signature
Re: IP over IEEE1394?
David Leimbach writes: True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. From my experience with the Apple IP over Firewire, it seems slow, and very high overhead. A dual 800MHz G4 host which can transmit at well over 1 Gb/sec (using ethernet-over-Myrinet) maxes its CPU out at 200Mb/sec, or less with IP over Firewire. (I'd report GigE numbers, but I don't have a GigE switch or a decent enough cable to get a host-host link at 1Gb/s). Its possible that the Apple code just sucked, I don't know. It used a 1500 byte mtu, for example. I'd have thought you'd be able to have much large mtus w/firewire. If the Apple code is typical, then I think that unless you've got some sort of alternate zero-copy protocol running over raw firewire, you'd be better off running GigE, or even multiple 100Mb links. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
If toy are using PVM or similar technologies, would'nt the best route to be to pick a transport that is the fastest. Last thing you want is messages to be bogged down in transport. Im nut sure what type of clusters you are building but I would say use multiple interfaces. If you are stuck with 1U per node, use a multi-port NIC. I have a D-Link card that as 4 interfaces on one flange. If you are stuck to blade servers, I'm not sure what to do other than place them all on a private back bone. Then have one brain that could be a gateway to them and the main network. I would stay away from message passing over slow links. You could use the firewall for heartbeat. On Wed, 2003-03-05 at 09:32, David Leimbach wrote: True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave On Wednesday, March 5, 2003, at 08:30 AM, Christopher Fowler wrote: The beauty of ppp is that you have support in the kernel to do it. Else, you are stuck to writing some type of interface driver for the kernel. In the short term, this may not be a workable solution. On a side note, I read an article on /. about using firewire + MinDV for backup. I guess I can get some use out of my camera after all. Chris On Wed, 2003-03-05 at 09:21, David Leimbach wrote: Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. --- -- -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) --- -- -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. That's just being silly. ISA support is still very much a requirement. Laptops usually have ISA stuff in them. Even modern systems do. My Shuttle box developed all sorts of issues when I removed ISA support from the kernel. They were all solved when I put it back in. We're talking about legacy stuff IN USE. If no one noticed it was broken for years then no one used it. It all seems like there was zero interest in in until it was announced that it was going away and suddenly someone wants to keep it around and submit patches, etc. It wasn't a case of I'm still using it, here's a patch to make it work. It was I did some work last night to patch it so it would compile. Those are 2 VERY different arguments. I would say that you should submit your patches and documentation by all means should anyone in the future. But if no one needs it, the code should be retired. Lack of a maintainer, lack of a userbase, issues with kernel maintenance are all valid reasons to retire code. This is code that the manufacturer wanted kept years ago and then didn't bother to keep up their end of the bargain. Fix it if you want, but it should probably be axed. My probably uninformed .02$. -Chris Corayer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mdmfs broken?
In article [EMAIL PROTECTED] you wrote: What's the correct syntax in 5-CURRENT to have a memory disk for /tmp in your /etc/fstab? [...] Create a symlink: lrwxr-xr-x 1 root wheel 5 Feb 13 13:28 /sbin/mount_mfs - mdmfs and use in /etc/fstab something like: md0 /tmp mfs rw,-s128m,noatime,nosuid,nodev 0 0 Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 07:43:15AM -0600, Jacques A. Vidrine wrote: On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. At least in the case of net/net-snmp the problem is that the shared lib version of the openssl port was bumped when the base wasn't which screws up the dependencies. :-( -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 pgp0.pgp Description: PGP signature
RE: boot0cfg
On 05-Mar-2003 [EMAIL PROTECTED] wrote: Last weekend I had to reinstall Windows XP on my PC and certainly I lost boot manager. After booting from CD and mounting as root ad0 device, I replaced boot0 record using the following command line : # boot0cfg -Bv -s 1 -t 91 ad0 On my PC I have 14G Windows XP partition(primary partition), 7G Linux (2 extended partitions) and 7G FreeBSD 5.0 - Current (primary partition). On second disk I have Windows 98. After installing I see something like this : F1 - ??? F3 - FreeBSD F5 - Disk 2 It is strange that only F1 works (start Windows XP), while F3 play some sound. Pressing F5 starts Windows XP, but it could be because Windows on my second disk. Yes I know that there are other boot managers like GRUB, but it is another beer. You need to turn on 'packet' mode by hand. # boot0cfg -o packet ad0 should do the trick. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Another nVidia question, maybe a bit OT.
Because of the repeated breakage of the proprietary nVidia driver in -CURRENT I've been trying out the native XFree86 'nv' driver with some puzzling results. Maybe one of the nVidia whiz-kids in this group can explain: I reboot the machine, then start the X server. The X server immediately aborts with an unresolved symbol vgaHWUnmapMem in nv_drv.o. Okay, so I forgot to load some module in my XF86Config, right? Wrong. All I need to do to is to start X a *second* time and the unresolved symbol error goes away like magic and X starts up. It took me a good while to discover that :-( How the hell does an unresolved symbol get resolved just by retyping the same command? My thought was to look for some kernel module that got loaded in the background, but no. Same kernel modules before and after. And the problem reappears after the next reboot. Any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Disk Read Errors under SMP on -current
Running -current updated less than a day ago (same problem existed a few days before), I am getting odd errors inserted in files (generally a string of five or so garbage characters randomly replacing file contents) when files are read. Doesn't seem to affected writes at all, but I didn't hang round long enough for exhaustive testing. Seems random as to which files are affected and when, and is causing plenty of programs to dump core (usually by seg fault, sometimes by illegal instruction). It's happening on all three of my disks, on two separate controllers. System is rock-solid stable with SMP disabled. Anyone got any ideas, or does this require further investigation and/or a proper problem report? (No SMP-incompatible options in my kernel or something stupid is there?) Motherboard is an Asus PCI/E-P54NP4, dmesg and kernel config follows. Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #1: Wed Mar 5 23:40:24 EST 2003 [EMAIL PROTECTED]:/opt/obj/opt/src/sys/HILLY.smp Preloaded elf kernel /boot/kernel/kernel at 0xc041. Timecounter i8254 frequency 1193182 Hz CPU: Pentium/P54C (133.33-MHz 586-class CPU) Origin = GenuineIntel Id = 0x52c Stepping = 12 Features=0x3bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,APIC real memory = 67108864 (64 MB) avail memory = 60743680 (57 MB) APIC_IO: MP table broken: 8259-APIC entry missing! Programming 16 pins in IOAPIC #0 EISA INTCONTROL = c600 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00030010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00030010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec0 Intel Pentium detected, installing workaround for F00F bug Allocating major#253 to net Allocating major#252 to pci npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.00 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 eisab0: PCI-EISA bridge at device 2.0 on pci0 eisa0: EISA bus on eisab0 mainboard0: ASU5101 (System Board) on eisa0 slot 0 ahc0: Adaptec 274X SCSI adapter at 0x3c00-0x3cff, irq 14 (level) ahc0: on eisa0 slot 3 aic7770: Twin Channel, A SCSI Id=7, B SCSI Id=7, primary B, 4/253 SCBs bt0: Buslogic 74xB SCSI host adapter at 0x330-0x333, 0x4c00-0x4cff bt0: irq 15 (level) on eisa0 slot 4 bt0: BT-742AH FW Rev. 3.31 Narrow SCSI Host Adapter, SCSI ID 7, 30 CCBs isa0: ISA bus on eisab0 xl0: 3Com 3c905-TX Fast Etherlink XL port 0xe800-0xe83f irq 10 at device 6.0 on pci0 xl0: Ethernet address: 00:10:4b:22:4c:b5 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: display, VGA at device 7.0 (no driver attached) orm0: Option ROMs at iomem 0xec000-0xe,0xdc000-0xd,0xd8000-0xdbfff,0xc-0xc7fff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x64,0x60 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: Enhanced floppy controller (i82077, NE72065 or clone) at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 fd1: 1200-KB 5.25 drive on fdc0 drive 1 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec Waiting 5 seconds for SCSI devices to settle Mar 6 00:22:53 hilly kernel: da3 at bt0 bus 0 target 0 lun 0 Mar 6 00:22:53 hilly kernel: da3: QUANTUM FIREBALL1280S 630G Fixed Direct Access SCSI-2 device Mar 6 00:22:53 hilly kernel: da3: 10.000MB/s transfers (10.000MHz, offset 8) Mar 6 00:22:53 hilly kernel: da3: 1222MB (2503872 512 byte sectors: 128H 32S/T 611C) Mar 6 00:22:54 hilly kernel: cd0 at ahc0 bus 0 target 4 lun 0 Mar 6 00:22:54 hilly kernel: cd0: TOSHIBA CD-ROM XM-5401TA 3115 Removable CD-ROM SCSI-2 device Mar 6 00:22:54 hilly kernel: cd0: 4.032MB/s transfers (4.032MHz, offset 15) Mar 6 00:22:54 hilly kernel: cd0: cd present [306178 x 2048 byte records] Mar 6 00:22:54 hilly kernel: da0 at ahc0 bus 1 target 0 lun 0 Mar 6 00:22:54 hilly kernel: da0: CONNER CFA540S P113 Fixed Direct Access SCSI-2 device Mar 6 00:22:54 hilly kernel: da0: 10.000MB/s transfers (10.000MHz, offset 15) Mar 6 00:22:54 hilly kernel: da0: 515MB (1056708 512 byte sectors: 64H 32S/T 515C) da1 at ahc0 bus 0 target 0 lun 0 da1: SEAGATE ST12550N 0013 Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 2040MB (4178874 512 byte sectors: 64H 32S/T 2040C) da2 at ahc0 bus 0 target 5 lun 0 da2: IOMEGA ZIP 100 J.03 Removable Direct Access SCSI-2 device da2: 3.300MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present SMP: AP CPU #1 Launched!
Re: Plea for base system trim
I use this command in my build script to force apache13+modssl to use the openssl in base. # Use base openssl (OpenSSL 0.9.7a as of Feb 19 2003) cd /usr/ports/www/apache13-modssl cp Makefile Makefile- sed -ie 's/^\.include.*Makefile\.ssl.*$/OPENSSLBASE=\/usr/' Makefile- Makefile You wrote: On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. Cheers, - -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] Adrian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 08:54:28AM -0800, Brooks Davis wrote: At least in the case of net/net-snmp the problem is that the shared lib version of the openssl port was bumped when the base wasn't which screws up the dependencies. :-( That's part of the problem. The port bumped the shared library version, even though it installed ABI-compatible library. Moreover, it bumped it to a new version number that was only 1 higher, almost designed to cause trouble :-) If all OpenSSL-using ports used `-rpath', then this wouldn't be a problem. But that is kind of a burden. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: bluetooth device ID
Hello Pav, [ CC'ed to [EMAIL PROTECTED] ] To all FreeBSD Bluetooth users Please do not hesitate to ask questions! No question is too dumb. When asking questions please CC to one of the FreeBSD mailing lists. mobile@, net@ and [EMAIL PROTECTED] seems like a good choice. This way your questions/reports (and my answers) will get into archive. Also it would be much easier to track number of users and progress of the project. i purchased usb bluetooth module and had a short play with friend's 5.0-RELEASE system and your bluetooth stack. device works fine it seems. Thanks for the report :) i would like to submit deviceid and vendorid so it's name is printed when you attach the device - whom should i contact? For now you should submit all patches to me :) ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 vendor: Anycom product: Bluetooth USB-100 Adapter Here is website http://www.anycom.com/products/usb.html Hmm... Another case of re-branding (i think). The same vendor/product pair already registered in the ng_ubt(4) driver as USB_VENDOR_EPOX 0x0a12 /* EPoX www.epox.com */ USB_PRODUCT_BT_DG02_DONGLE 0x0001 /* EPoX BT-DG02 USB dongle */ thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
On Wed, Mar 05, 2003 at 07:25:20AM -0600, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. The interconnect is just 10% of the whole cluster story. Firewire is one possibility, but Fibrechannel you could do today if you wanted to. We have Fibrechannel support in the Qlogic isp(4) driver (thanks Matt!) today. W/ -- | / o / /_ _ [EMAIL PROTECTED] |/|/ / / /( (_) Bulte To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
I have both apache-modssl and net-snmp running, but do NOT have the openssl port installed. Everything builds and runs fine, with no mods to anything. I conjecture that the problem others experience is that they have installed the openssl port, which I have never done. This is on both current and stable. On Wed, Mar 05, 2003 at 06:00:13PM +0100, Adrian Steinmann wrote: I use this command in my build script to force apache13+modssl to use the openssl in base. # Use base openssl (OpenSSL 0.9.7a as of Feb 19 2003) cd /usr/ports/www/apache13-modssl cp Makefile Makefile- sed -ie 's/^\.include.*Makefile\.ssl.*$/OPENSSLBASE=\/usr/' Makefile- Makefile You wrote: On Wed, Mar 05, 2003 at 09:54:13AM -, Subscriber wrote: Having just done two rebuilds for recent OpenSSL and sendmail vulnerabilities, I was surprised to discover that building the port of apache13-modssl required the build of a port version of OpenSSL when I had the most updated (4.7) base system with OpenSSL in it!. I hate having two versions installed; it makes me fear that there will be problems caused by the wrong version being used. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, Mar 05, 2003 at 01:15:29PM -0500, Barney Wolff wrote:
I have both apache-modssl and net-snmp running, but do NOT have the
openssl port installed. Everything builds and runs fine, with no
mods to anything. I conjecture that the problem others experience
is that they have installed the openssl port, which I have never done.
This is on both current and stable.
Oops, not net-snmp, net-snmp4 (aka ucd-snmp). net-snmp doesn't appear
to have a dependency on openssl at all.
Here's a log:
[10:19am] [EMAIL PROTECTED] (/usr/ports/net/net-snmp4): pkg_info openssl\*
pkg_info: can't find package 'openssl*' installed or in a file!
[10:19am] [EMAIL PROTECTED] (/usr/ports/net/net-snmp4): portversion openssl
** No package matching 'openssl' was found.
[10:19am] [EMAIL PROTECTED] (/usr/ports/net/net-snmp4): sudo make
Password:
You may use the following build options:
WITH_PORTSSL=yes Use the OpenSSL Version delivered by the ports.
With FreeBSD 5, net-snmp4 requires automaticly
the OpenSSL ports-version. In the 5 case, you
don't need to define WITH_PORTSSL (default).
WITHOUT_SSL=yes Disable the OpenSSL support.
=== Extracting for ucd-snmp-4.2.6
Checksum OK for ucd-snmp-4.2.6.tar.gz.
=== Patching for ucd-snmp-4.2.6
=== Applying FreeBSD patches for ucd-snmp-4.2.6
=== Configuring for ucd-snmp-4.2.6
=== ucd-snmp-4.2.6 depends on file: /usr/local/libexec/autoconf213/autoconf - found
=== ucd-snmp-4.2.6 depends on executable: libtool - found
=== ucd-snmp-4.2.6 depends on file: /usr/local/bin/perl5.6.1 - found
=== ucd-snmp-4.2.6 depends on shared library: crypto.4 - not found
===Verifying install for crypto.4 in /usr/ports/security/openssl
openssl-0.9.7a.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
Attempting to fetch from http://www.openssl.org/source/.
[...]
The problem is that this line forces WITH_PORTSSL with recent OS versions.
.if defined(WITH_PORTSSL) || ${OSVERSION} = 500100 || (${OSVERSION} = 470103
${OSREL} == 4)
-- Brooks
--
Any statement of the form X is the one, true Y is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgp0.pgp
Description: PGP signature
Fix for rtc, vmware modules and post-500104 -current
See the patches enclosed to emulators/rtc
and emulators/vmware2 ports.
Tested only for -current with:
#define __FreeBSD_version 500104
--
Marcin Cielak // [EMAIL PROTECTED]
Index: Makefile
===
RCS file: /home/ncvs/ports/emulators/rtc/Makefile,v
retrieving revision 1.12
diff -u -u -r1.12 Makefile
--- Makefile16 Sep 2001 07:01:44 - 1.12
+++ Makefile5 Mar 2003 17:36:37 -
@@ -6,7 +6,7 @@
#
PORTNAME= rtc
-PORTVERSION= 2001.09.16.1
+PORTVERSION= 2002.03.05.1
CATEGORIES=emulators linux
MASTER_SITES= # none
DISTFILES= # none
Index: files/rtc.c
===
RCS file: /home/ncvs/ports/emulators/rtc/files/rtc.c,v
retrieving revision 1.6
diff -u -u -r1.6 rtc.c
--- files/rtc.c 16 Sep 2001 07:05:18 - 1.6
+++ files/rtc.c 5 Mar 2003 17:36:25 -
@@ -85,6 +85,14 @@
static int rtc_modeevent(module_t mod, int cmd, void *arg);
static struct cdevsw rtc_cdevsw = {
+#if __FreeBSD_version = 500104
+ .d_open = rtc_open,
+ .d_close = rtc_close,
+ .d_ioctl = rtc_ioctl,
+ .d_poll = rtc_poll,
+ .d_name = DEVICE_NAME,
+ .d_maj =CDEV_MAJOR,
+#else
/* open */ rtc_open,
/* close */ rtc_close,
/* read */ noread,
@@ -101,6 +109,7 @@
#if __FreeBSD_version = 500018
/* bmaj */ -1,
#endif
+#endif
#if __FreeBSD_version = 500018 || __FreeBSD_version = 43
/* kqfilter */ nokqfilter,
#endif
@@ -264,11 +273,13 @@
static int
init_module(void)
{
-int error;
+ int error = 0;
+#if __FreeBSD_version 500104
error = cdevsw_add(rtc_cdevsw);
if (error)
return error;
+#endif
return error;
}
@@ -286,7 +297,9 @@
DLog(Lfail, %p busy, sc);
return error;
}
+#if __FreeBSD_version 500104
error = cdevsw_remove(rtc_cdevsw);
+#endif
DLog(Linfo, return %d, error);
return error;
}
Index: Makefile
===
RCS file: /home/ncvs/ports/emulators/vmware2/Makefile,v
retrieving revision 1.48
diff -u -u -r1.48 Makefile
--- Makefile21 Feb 2003 11:59:00 - 1.48
+++ Makefile5 Mar 2003 18:27:21 -
@@ -93,6 +93,9 @@
.if ${OSVERSION} = 500027
cat ${FILESDIR}/pmap.patch | (cd ${WRKSRC} patch) /dev/null 21
.endif
+.if ${OSVERSION} = 500104
+ cat ${FILESDIR}/cdevsw.patch | (cd ${WRKSRC} patch) /dev/null 21
+.endif
${CP} ${FILESDIR}/Makefile ${WRKSRC}
${CP} ${FILESDIR}/Makefile.vmmon ${WRKSRC}/vmmon-only/Makefile
${RM} -rf ${WRKSRC}/vmmon-only/linux/
Index: files/cdevsw.patch
===
RCS file: files/cdevsw.patch
diff -N files/cdevsw.patch
--- /dev/null 1 Jan 1970 00:00:00 -
+++ files/cdevsw.patch 5 Mar 2003 18:25:13 -
@@ -0,0 +1,130 @@
+--- vmmon-only/freebsd/driver.c_original Wed Mar 5 19:22:35 2003
vmmon-only/freebsd/driver.cWed Mar 5 19:22:44 2003
+@@ -155,6 +155,14 @@
+
+ /* static struct cdevsw vmmon_cdevsw = { */
+ static struct cdevsw vmmon_cdevsw = {
++#if __FreeBSD_version = 500104
++ .d_open = FreeBSD_Driver_Open,
++ .d_close = FreeBSD_Driver_Close,
++ .d_ioctl = FreeBSD_Driver_Ioctl,
++ .d_poll = FreeBSD_Driver_Poll,
++ .d_name = DEVICE_NAME,
++ .d_maj =CDEV_MAJOR
++#else
+ /* open */ FreeBSD_Driver_Open,
+ /* close */ FreeBSD_Driver_Close,
+ /* read */ noread,
+@@ -169,8 +177,7 @@
+ /* psize */ nopsize,
+ /* flags */ 0,
+ /* bmaj */ -1
+-
+-
++#endif
+ };
+
+
+@@ -242,7 +249,11 @@
+sprintf(freebsdState.deviceBuf,DEVICE_NAME);
+freebsdState.major = CDEV_MAJOR;
+freebsdState.minor = CDEV_MINOR;
++#if __FreeBSD_version 500104
+retval = cdevsw_add(vmmon_cdevsw);
++#else
++ retval = 0;
++#endif
+
+ #endif
+if (retval) {
+@@ -273,12 +284,14 @@
+int retval=0;
+
+destroy_dev(vmmon_dev);
++#if __FreeBSD_version 500104
+retval = cdevsw_remove(vmmon_cdevsw);
+if (retval) {
+ Warning(Module %s: error unregistering\n, freebsdState.deviceBuf);
+} else {
+ Log(Module %s: unloaded\n, freebsdState.deviceBuf);
+}
++#endif
+
+return 0;
+ }
+--- vmnet-only/freebsd/vmnet.c_originalWed Mar 5 19:21:51 2003
vmnet-only/freebsd/vmnet.c Wed Mar 5 19:22:00 2003
+@@ -103,6 +103,16 @@
+ static int vmnet_modeevent(module_t mod, int cmd, void *arg);
+
+ static struct cdevsw vmnet_cdevsw = {
++#if __FreeBSD_version = 500104
++ .d_open = vmnet_open,
++ .d_close = vmnet_close,
++ .d_read = vmnet_read,
++ .d_write = vmnet_write,
++ .d_ioctl = vmnet_ioctl,
++ .d_poll =
Re: Removal of netns - politically correct version
Hiten Pandya wrote: Sorry to but in, but I don't see why this so called bikesheed keeps getting bigger and bigger. The outcome is simple. If your patches function properly, then there is no need to remove netns provided you don't mind maintaining it. If it doesn't have a maintainer, then just apply your fixes and shuv it in the Attic so it's less horid when someone wants to restart the effort of maintaining it. I am willing to take and respond to all bug reports about the code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Freeze after APIC_IO: Testing 8254 interrupt delivery
Hello, Our newly bought Fujitsu-Siemens F250 boots with the GENERIC kernel, but with a recent, SMP-capable CURRENT it freezes after the following line: APIC_IO: Testing 8254 interrupt delivery No response to keyboard activity (I have a KVM extender on the machine, its LED blinks, it does the same when I unplug the other side from the machine's keyboard connector). The strange thing is that I build a CURRENT kernel on monday, or tuesday and it also did this, but when I disabled ACPI with hint.acpi.0.disable=1 it worked. Now I compiled a new kernel (because I missed the DDB support in the previous) and it freezes, no matter the ACPI is loaded or not. Any ideas? ps: the machine is a dual Xeon with HTT enabled. Thanks, --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: boot0cfg
From: [EMAIL PROTECTED] Date: Wed, 5 Mar 2003 09:25:53 +0200 Sender: [EMAIL PROTECTED] Last weekend I had to reinstall Windows XP on my PC and certainly I lost boot manager. After booting from CD and mounting as root ad0 device, I replaced boot0 record using the following command line : # boot0cfg -Bv -s 1 -t 91 ad0 On my PC I have 14G Windows XP partition(primary partition), 7G Linux (2 extended partitions) and 7G FreeBSD 5.0 - Current (primary partition). On second disk I have Windows 98. After installing I see something like this : F1 - ??? F3 - FreeBSD F5 - Disk 2 It is strange that only F1 works (start Windows XP), while F3 play some sound. Pressing F5 starts Windows XP, but it could be because Windows on my second disk. Yes I know that there are other boot managers like GRUB, but it is another beer. I haven't enough time to investigate where the problem is (boot0 code), but this evening I should. The problem is that the boot block installed by default is limited to booting systems located in the first 1023 cylinders of the disk and XP is so big that the second partition is now often past that point. Any reasonably modern BIOS will support a slightly different boot record which can boot a partition anywhere on disk. The hitch is that this boot block will not work at all on some older systems. To use this more modern boot block, add '-o packet' to the boot0cfg command. This is in the man page, but the man page does not make it clear what the real significance of this option is. I think it should be referenced VERY clearly in the description section of the man page. For any system less than about 4 year old and may older systems, you really want to use this option. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Freeze after APIC_IO: Testing 8254 interrupt delivery
On 2003.03.05 20:52:21 +0100, Attila Nagy wrote: Our newly bought Fujitsu-Siemens F250 boots with the GENERIC kernel, but with a recent, SMP-capable CURRENT it freezes after the following line: APIC_IO: Testing 8254 interrupt delivery I had the same problem with a FSC P250 (same motherboard) using 4.7-REL. It works in SMP mode with a recent 4-STABLE (after MFC of HTT). It appears to only work if HyperThreading is enabled. John Baldwin commited changes to -CURRENT a few days ago to disable HTT unless it is explicitly enabled in the kernel config file. That could be the problem. I'm currently trying to get it to work without HTT enabled but so far not succeeding. -- Simon L. Nielsen pgp0.pgp Description: PGP signature
Re: Freeze after APIC_IO: Testing 8254 interrupt delivery
Hello, I had the same problem with a FSC P250 (same motherboard) using 4.7-REL. It works in SMP mode with a recent 4-STABLE (after MFC of HTT). It appears to only work if HyperThreading is enabled. False alarm. I switched from cvsup.freebsd.org to cvsup2.freebsd.org, updated the tree, recompiled and it works again. Thanks! --[ Free Software ISOs - http://www.fsn.hu/?f=download ]-- Attila Nagy e-mail: [EMAIL PROTECTED] Free Software Network (FSN.HU)phone @work: +361 210 1415 (194) cell.: +3630 306 6758 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: boot0cfg
Kevin Oberman [EMAIL PROTECTED] wrote: For any system less than about 4 year old and may older systems, you really want to use this option. The other possibility, if both FreeBSD and XP are installed on the same disk, is to just use XP's boot selector to select which one to boot. It can be a lot easier than having to deal with boot sector issues. For more information, see: http://bsdatwork.com/sections.php?op=viewarticleartid=3 (This is for the case where Windows FreeBSD are on the SAME drive.) (Also read the OpenBSD section for additional WinXP info.) http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#NT-BOOTLOADER -- Darryl Okahata [EMAIL PROTECTED] DISCLAIMER: this message is the author's personal opinion and does not constitute the support, opinion, or policy of Agilent Technologies, or of the little green men that have been following him all day. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Kerberos IV exiting tree for 5.1-RELEASE
Hello Gentlefolk, In the next couple of weeks, I will be removing Kerberos IV from -CURRENT. I will also be re-organizing the Kerberos 5 bits so that the utilities have their `normal' names (e.g. `kinit' rather than `k5init') and replacing Kerberos 4 support with Kerberos 5 support in applications so far as that is possible (e.g. TELNET, cvs). For those of you who do use Kerberos IV, I would appreciate it very much if you could try the security/krb4 port. If you run into trouble or have suggestions, please let me know. Better yet, send patches for the port! In fact, if you are a committer that uses Kerberos IV, please consider maintaining the security/krb4 port. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-O2 broke ppp NAT
Hello to all, For the first time I compile current-p3 - current-p4 with -march=pentium2 -O2 -mmmx -pipe and aparently everything works ok except ppp -nat. NAT just don't work on my network. All machines are able to ping except ftp, http, etc. I rebuild everything with no CPUTYPE? and CFLAGS and ppp -nat is working again. I know that this isn't a important issue or bug because there are lots of warnings about gcc optimizations because the system may become unstable. I will not use extra optitimization on my buildsi anymore. A good lesson. Thanks very much, Nuno Teixeira -- /* PGP fingerprint: C6D1 06ED EB54 A99C 6B14 6732 0A5D 810D 727D F6C6 */ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, 5 Mar 2003, Adrian Steinmann wrote: I use this command in my build script to force apache13+modssl to use the openssl in base. # Use base openssl (OpenSSL 0.9.7a as of Feb 19 2003) cd /usr/ports/www/apache13-modssl cp Makefile Makefile- sed -ie 's/^\.include.*Makefile\.ssl.*$/OPENSSLBASE=\/usr/' Makefile- Makefile You could instead do: sed pattern Makefile makefile The lowercase makefile will be used by make in preference to Makefile. You are right to hate having two versions installed --- it is pointless in most cases. Please complain to the apache+mod_ssl and openssl port maintainers. It sounds to me like they are doing something very wrong. Seconded. Getting the lib version numbers out of synch for the same openssl version in base and ports sounds like a big, big accident waiting to happen. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADSUP: GEOM/devstat centralization patch
Ok, next in the NO_GEOM cleanup series: http://phk.freebsd.dk/patch/devstat.patch This patch centralizes the devstat handling for all disk device drivers under GEOM in geom_disk.c As a side effect this makes 40 #include sys/devicestat.h lines surplus to requirements and some biofinish() calls gets simplified so they can become biodone() calls (again). The total savings are 140 lines. I plan to commit this patch on saturday. Reviews and test-reports most welcome. Poul-Henning PS: This is the list of affected files: Index: alpha/alpha/autoconf.c Index: cam/cam_periph.h Index: cam/cam_xpt.c Index: cam/scsi/scsi_da.c Index: cam/scsi/scsi_low.c Index: cam/scsi/scsi_ses.c Index: contrib/dev/fla/fla.c Index: dev/aac/aac.c Index: dev/aac/aac_cam.c Index: dev/aac/aac_debug.c Index: dev/aac/aac_disk.c Index: dev/aac/aac_pci.c Index: dev/aac/aacvar.h Index: dev/amr/amr.c Index: dev/amr/amr_cam.c Index: dev/amr/amr_compat.h Index: dev/amr/amr_disk.c Index: dev/amr/amr_pci.c Index: dev/amr/amrvar.h Index: dev/ata/ata-all.c Index: dev/ata/ata-disk.c Index: dev/ata/ata-disk.h Index: dev/ata/ata-raid.c Index: dev/ata/atapi-cam.c Index: dev/ata/atapi-fd.c Index: dev/ata/atapi-fd.h Index: dev/ccd/ccd.c Index: dev/ciss/ciss.c Index: dev/firewire/sbp.c Index: dev/ida/ida.c Index: dev/ida/ida_disk.c Index: dev/ida/ida_eisa.c Index: dev/ida/ida_pci.c Index: dev/ida/idavar.h Index: dev/md/md.c Index: dev/mlx/mlx.c Index: dev/mlx/mlx_compat.h Index: dev/mlx/mlx_disk.c Index: dev/mlx/mlx_pci.c Index: dev/mlx/mlxvar.h Index: dev/mly/mly.c Index: dev/ofw/ofw_disk.c Index: dev/ppbus/vpo.c Index: dev/pst/pst-raid.c Index: dev/raidframe/rf_freebsdkintf.c Index: dev/twe/twe_compat.h Index: dev/twe/twe_freebsd.c Index: dev/usb/umass.c Index: dev/vinum/vinum.c Index: geom/geom_disk.c Index: ia64/ia64/autoconf.c Index: ia64/ia64/sscdisk.c Index: pc98/pc98/wd.c Index: sys/ccdvar.h Index: sys/disk.h -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: boot0cfg
On Thu, 2003-03-06 at 03:26, John Baldwin wrote: It is strange that only F1 works (start Windows XP), while F3 play some sound. Pressing F5 starts Windows XP, but it could be because Windows on my second disk. Yes I know that there are other boot managers like GRUB, but it is another beer. You need to turn on 'packet' mode by hand. # boot0cfg -o packet ad0 should do the trick. Do you think this should be the default? ie would it fix more things than it breaks? My feeling is yes... Or is sysinstall supposed to set the flags based on where you install stuff? (I had a quick look but couldn't see anything to indicate this was so) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: IP over IEEE1394?
On Thu, 2003-03-06 at 01:06, Cagle, John (ISS-Houston) wrote: Wouldn't you need a firewire switch to do a cluster of more than 2 nodes? Or are you thinking of using multiple firewire interfaces per node? Firewire supports daisy chaining devices, and multiple masters. I have done laptop - firewire hd - desktop PC and used the drive on one machine and setup a network between the two of them :) fwcontrol -t shows bus topology. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed Mar 05, 2003 at 02:29:00PM -0800, Doug Barton wrote: On Wed, 5 Mar 2003, Adrian Steinmann wrote: I use this command in my build script to force apache13+modssl to use the openssl in base. # Use base openssl (OpenSSL 0.9.7a as of Feb 19 2003) cd /usr/ports/www/apache13-modssl cp Makefile Makefile- sed -ie 's/^\.include.*Makefile\.ssl.*$/OPENSSLBASE=\/usr/' Makefile- Makefile You could instead do: sed pattern Makefile makefile The lowercase makefile will be used by make in preference to Makefile. Juste jumping in... Couldn't you just: sed -i.orig -e pattern Makefile For example: [EMAIL PROTECTED] cat foo this is a test [EMAIL PROTECTED] sed -i.orig -e 's/test/gizmo/' foo [EMAIL PROTECTED] diff -u foo.orig foo --- foo.origWed Mar 5 17:54:09 2003 +++ foo Wed Mar 5 17:54:13 2003 @@ -1 +1 @@ -this is a test +this is a gizmo Much simpler, unless I missed something. A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On 2003-03-05 02:14:16 (-0800), Doug Barton [EMAIL PROTECTED] wrote: On Wed, 5 Mar 2003, Subscriber wrote: Would the powers that be please consider removing sendmail, bind and openssl from the base system, as was done for perl with 5.0? For example, as BIND maintainer I actually _support_ the theory of removing BIND, however the reality is a little different. There are three main components of BIND; the named stuff (sbin/named, sbin/ndc, etc.), the userland stuff (dig, host, etc.), and the resolver library. Of those three things, we actually need the last two in order to include ourselves in a useful definition of Unix system Is it actually possible for one to build a custom release without the ``unnecessary'' BIND bits? I haven't grepped the source, forgive me, but what does 'NO_BIND=true' actually do? If I were to make a release like that, would that end me up without resolver as well? Likewise, would building 'NO_SENDMAIL=true' build me a pristine system void of Sendmail bits, or will there always be some stuff left? If those two knobs do what they promise to do, it should be fairly trivial to compare a custom release tree with the installed base, and nuke the things one doesn't like from the base-system at will? Or am I missing something? :-) I'm pretty happy about having BIND and Sendmail in the base-system. Disk space costs nearly nothing these days, and as long as they're not running (and have their executable bits stripped, 'just in case'), I don't particularly mind them taking up a few bytes of room. (although I'd LOVE to nuke nslookup, if I thought I could ever live down the whining and crying it would cause). :-) Perhaps a NO_NSLOOKUP flag? ;-) So keeping BIND in the base actually serves a purpose. Similar arguments can be made for the other components you listed. Definitely! Now that said, I've been working off and on to make it easier to replace parts of the base with stuff from the ports. Both BIND ports have PORT_REPLACES_BASE_ Makefile options, and I know that they are useful because I use them at work. I just spotted those flags a few days ago. They're very useful. Now my fiddling with the BIND port is reduced to making stuff live under /var/namedb instead of /etc/namedb as I like having / mounted read-only as much as possible. - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #193: Did you pay the new Support Fee? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Bluetooth stack for FreeBSD
Dear Hackers, I'm very pleased to announce that another release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030305.tar.gz The Bluetooth sockets layer has been cleaned up. People should not see any WITNESS complains with new code. Locking issues have been revisited and code in much better shape now, although it probably is not 100% SMP ready just yet. The code should work on SMP system anyway because sockets layer is still under Giant. Minor bug in OpenOBEX library has been fixed and OPEX Put-Empty command now works. Also ng_ubt(4) now supports Wireless Transceiver for Bluetooth from Microsoft. Thanks to Dustin Boontheekul [EMAIL PROTECTED] for testing. IMPORTANT! Due to changes in API userland tools must be in sync with the kernel. People should install new include files, recompile and reinstall all userland tools as part of upgrade. I'm sorry about that. IMPORTANT! New taskqueue_swi_giant has been introduces recently in FreeBSD. The socket code has been converted to use it. If you system is not recent you will need 1) upgrade to recent -current or 2) change taskqueue_swi_giant to taskqueue_swi and compile code. People are advised to upgrade and try the new code. Please do ask question and submit success stories/bug reports to me. Please also CC to one the FreeBSD mailing lists (mobile, net or current) for archive purposes. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: SCHED_ULE ok again. feedback please?
My first impression of SCHED_ULE is slow. I only say this because the first thing I
fire up after starting X is Eterm with a transparant+shaded theme. Even with the old
scheduler this Eterm wasn't too snappy, but with SCHED_ULE it hangs X for about 1-2
seconds. I'm currently running a kernel compile and everything still isn't as fluid as
before and the mouse is quite jumpy. Still, seems better then what I experienced a
week ago.
I'll be happy to keep compiling when you check in updates. I buildworld/kernel almost
every day.
James.
On Tue, 4 Mar 2003 01:25:24 -0500 (EST)
Jeff Roberson [EMAIL PROTECTED] wrote:
I'm using SCHED_ULE on my laptop now. My recent round of fixes seems to
have helped out. I'm getting good interactive performance. I'm doing the
following:
nice -5'd for (;;) {} process.
make -j4 buildworld
Mozilla, pine, irc, screen, vi, etc.
All interactive tasks are very responsive. My nice -5'd looping process
is getting 70% of the cpu and my compile is taking the rest. nice +20 may
not behave as well as in sched_4bsd right now. I'm going to work on that.
This is on a 2ghz laptop though so your mileage may vary. Use reports are
welcome.
Interactivity suffered so much over the last few weeks because I changed
the mechanism that determines interactivity and that impacts slice
assignment and priorities. It took me a while to get it right but it
solved a major drawback with the old scheme. I do not anticipate any
major rework on this part of the scheduler now. It should only be tuning.
One thing that I'm looking for feedback on specifically is expensive but
interactive applications. I'm thinking of office programs or mozilla on a
slow machine. Do this while running a compile or a compute bound task.
Thanks,
Jeff
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed, 5 Mar 2003, The Anarcat wrote: Juste jumping in... Couldn't you just: sed -i.orig -e pattern Makefile No, because sed -i is evil, and will cause you to have hairy palms. -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Wed Mar 05, 2003 at 03:52:22PM -0800, Doug Barton wrote: On Wed, 5 Mar 2003, The Anarcat wrote: Juste jumping in... Couldn't you just: sed -i.orig -e pattern Makefile No, because sed -i is evil, and will cause you to have hairy palms. What? A. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CVSROOT directory gone?
Ah... my bad thanks for the response. I wish I actually had time to read all the emails I actually get :) Dave On Wednesday, March 5, 2003, at 08:34 AM, Michael Hostbaek wrote: The following mail was sent to current@ from Peter Wemm yesterday: snip Anybody who uses the cvs-supfile example to get the repository should add cvsroot-all to their supfile. This is in addition to src-all, ports-all, doc-all etc. This is *ONLY* for the folks getting the CVS ,v files via cvsup. If you use tag=. or tag=RELENG_4, then you are not affected by this. I have updated cvs-supfile in -current but not RELENG_4 yet. Cheers, -Peter /snip /mich David Leimbach (leimy2k) writes: I can't seem to get a mirror copy of the CVSROOT directory with my cvsup script. This worked fine a few days ago. cvsup2.FreeBSD.org is the server I used. Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Best Regards, Michael Landin Hostbaek FreeBSDCluster.org - an International Community */ PGP-key available upon request /* To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
Well there are firewire hubs and the machines I typically do this on are Macs which generally have 2 firewire ports... you can make a small ring network that way. Dave On Wednesday, March 5, 2003, at 08:36 AM, Cagle, John (ISS-Houston) wrote: Wouldn't you need a firewire switch to do a cluster of more than 2 nodes? Or are you thinking of using multiple firewire interfaces per node? -Original Message- From: David Leimbach [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 8:32 AM To: Christopher Fowler Cc: [EMAIL PROTECTED] Subject: Re: IP over IEEE1394? True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
I hadn't thought of this Interesting :) Dave On Wednesday, March 5, 2003, at 08:41 AM, Christopher Fowler wrote: You can run IP via PPP. PPPD is used all the time for VPN. I've got 2 networks that are combined via PPPD over a tunnel because they are both on private networks and have only 1 public IP. However, The overhead could get you. I'm not sure you want to go down the writer of creating another interface. Maybe you could use the SLIP interface and capture that IP stuff and send across. On Wed, 2003-03-05 at 09:32, David Leimbach wrote: True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave On Wednesday, March 5, 2003, at 08:30 AM, Christopher Fowler wrote: The beauty of ppp is that you have support in the kernel to do it. Else, you are stuck to writing some type of interface driver for the kernel. In the short term, this may not be a workable solution. On a side note, I read an article on /. about using firewire + MinDV for backup. I guess I can get some use out of my camera after all. Chris On Wed, 2003-03-05 at 09:21, David Leimbach wrote: Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. - -- -- -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - -- -- -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On Thu, 6 Mar 2003, Philip Paeps wrote: Is it actually possible for one to build a custom release without the ``unnecessary'' BIND bits? I haven't grepped the source, forgive me, but what does 'NO_BIND=true' actually do? If I were to make a release like that, would that end me up without resolver as well? It's not as thorough as I think it should be. I plan to get cracking on this now that I've got my ports more or less whipped into shape pre-freeze. Perhaps a NO_NSLOOKUP flag? ;-) Yeah, I'll add that along with the PIGS_WILL_FLY flag. I just spotted those flags a few days ago. They're very useful. Good news, thanks. Now my fiddling with the BIND port is reduced to making stuff live under /var/namedb instead of /etc/namedb as I like having / mounted read-only as much as possible. One way you can do this fairly easily with PORT_REPLACES_BASE is to have your chroot tree look something like this: /var/named/other stuff you need /var/named/etc/namedb/named.conf (etc) Then have /etc/namedb be a symlink to /var/named/etc/namedb, with 'directory /etc/namedb;' in your named.conf file. That way, both named and ndc see the same picture of the system, in and out of the chroot tree. I already use this at work, and I plan to add a lot of this config to the base itself here pretty soon. But you can easily get a head start on it now using what I described above. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
On Wednesday, March 5, 2003, at 10:13 AM, Christopher Fowler wrote: If toy are using PVM or similar technologies, would'nt the best route to be to pick a transport that is the fastest. Last thing you want is messages to be bogged down in transport. Assuming you can afford the hundreds of thousands of dollars to purchase such a good transport sure :). Personally I don't think people should purchase clusters but they should purchase cluster time on a well configured server like a utility. IBM seems to believe this is true also. I would stay away from message passing over slow links. You could use the firewall for heartbeat. People do clustering with fast ethernet all the time. ... I know because we sell a lot of it where I work :). Gigabit ethernet is better but switches are costly. Dave On Wed, 2003-03-05 at 09:32, David Leimbach wrote: True... I guess I didn't state my case clearly enough that I think IP over firewire is in itself a good thing for clusters. ppp connections with it are fine too but not very useful for my line of work which is parallel computing middleware :) Dave On Wednesday, March 5, 2003, at 08:30 AM, Christopher Fowler wrote: The beauty of ppp is that you have support in the kernel to do it. Else, you are stuck to writing some type of interface driver for the kernel. In the short term, this may not be a workable solution. On a side note, I read an article on /. about using firewire + MinDV for backup. I guess I can get some use out of my camera after all. Chris On Wed, 2003-03-05 at 09:21, David Leimbach wrote: Yeah... point to point connections are interesting and powerful but IP would be better if we could get it. I wish I knew more about how to implement it. :) Dave On Wednesday, March 5, 2003, at 08:23 AM, Christopher Fowler wrote: This may not be a workable solution, but if you can get 2 programs to send data across the firewire to one another, you could use pppd through that tunnel. On Wed, 2003-03-05 at 08:25, David Leimbach wrote: Interesting... I didn't even know we had Ethernet over firewire :). Mac OS X and Windows XP both have IP over firewire either working or in the works and somewhat usable. The only one I can claim any experience with is Mac OS X. It's somewhat flaky though and you get unreliable spikes in some basic performance tests I have done with it. It would be a really interesting value added feature for FreeBSD 5.x and could potentially open FBSD up even more to the cluster market which is somewhere its not as proliferated as linux. With the advent of firewire2 on the horizon it may be even more impressive. I believe there is even an Oracle product for linux which can cluster databases over firewire now. [I don't know if its IP though] Dave On Wednesday, March 5, 2003, at 01:43 AM, Rossam Souza Silva wrote: Hi, there is some plan to port NetBSD's implementation of IP over Firewire? I know, we have Ethernet over Firewire, but like the Linux one, isn't a standard... Just curious. - -- -- -- --- (_ ) Contrary to popular belief, UNIX is user friendly. It just happens \\\'',) ^ to be very selective about who it decides to make friends with. \/ \( .\._/_) Rossam Souza Silva ([EMAIL PROTECTED]) - -- -- -- -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: IP over IEEE1394?
The interconnect is just 10% of the whole cluster story. Firewire is one possibility, but Fibrechannel you could do today if you wanted to. We have Fibrechannel support in the Qlogic isp(4) driver (thanks Matt!) today. Yeah... if you are lucky 10% :). In fact latency in messages isn't as important as some people would like you to believe either. A well written MPI library [and MPI application] allows overlap of communication and computation that improves the overall wall clock time of the job... which is the ultimate goal. Get it done correctly and get it done ASAP! :) but that's WY offtopic now :) Dave To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On 2003-03-05 16:46:04 (-0800), Doug Barton [EMAIL PROTECTED] wrote: On Thu, 6 Mar 2003, Philip Paeps wrote: Is it actually possible for one to build a custom release without the ``unnecessary'' BIND bits? I haven't grepped the source, forgive me, but what does 'NO_BIND=true' actually do? If I were to make a release like that, would that end me up without resolver as well? It's not as thorough as I think it should be. I plan to get cracking on this now that I've got my ports more or less whipped into shape pre-freeze. Thanks! The possibility of having a way to completely erradicate the 'superfluous' bits of BIND sounds very appealing. I'd be happy to break some machines to help test this :-) Perhaps a NO_NSLOOKUP flag? ;-) Yeah, I'll add that along with the PIGS_WILL_FLY flag. *grin* Now my fiddling with the BIND port is reduced to making stuff live under /var/namedb instead of /etc/namedb as I like having / mounted read-only as much as possible. One way you can do this fairly easily with PORT_REPLACES_BASE is to have your chroot tree look something like this: /var/named/other stuff you need /var/named/etc/namedb/named.conf (etc) Then have /etc/namedb be a symlink to /var/named/etc/namedb, with 'directory /etc/namedb;' in your named.conf file. That looks a lot cleaner than what I've got now. Good project for tomorrow morning. Also gets rid of the confusing (to some) directory /' in the config, and allows those obsessed with editing /etc/namedb/named.conf to find themselves at home. That way, both named and ndc see the same picture of the system, in and out of the chroot tree. Speaking of ndc, I think that's a BIND8-ism. Could the port be convinced to symlink it to rndc when set to replace the base, or would that confuse other things? Currently, I'm just aliasing it in my shell, but that seems a bit hackish :-) I already use this at work, and I plan to add a lot of this config to the base itself here pretty soon. But you can easily get a head start on it now using what I described above. Briliant! I'll have people congratulate me on the cleanliness of my nameserver by lunchtime tomorrow :-P - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. If you see a man approaching you with the obvious intent of doing you good, you should run for your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ATA MODE_SENSE_BIG timeout
- Original Message - From: Luoqi Chen [EMAIL PROTECTED] To: David Xu [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, March 05, 2003 8:44 AM Subject: RE: ATA MODE_SENSE_BIG timeout For those want to fix ATA code, I have another problem with CURRENT. I have a Tyan Tiger 230T which is based on VIA Apollo 133T, south bridge is VIA 686B. On second IDE, I have a Mitsubishi 52X cdrom as master, and a Sony 16X CD R/W as slave, when startup, kernel is always stuck at MODE_SENSE_BIG timeout. I fortunately catched the dmesg text since ATA code past the probing stage. In most case, it will be stuck there forever. BTW, both Linux (2.2.14, Redhat) and MS Windows can probe these devices in few seconds without any problem. I had more than a few machines behaved this way. I believe the problem is with the probe and attach sequence of our ata driver. After an ATA reset, according to spec, an ATAPI device is supposed to present the ATAPI signature and deassert the ready bit, until it receives its first packet command. However when the ata driver issues the first mode sense command, it polls first for the ready bit which never becomes set and the operation times out. The most obviously solution is sending the first command without checking for the ready bit. My solution is a little different, but works equally well, instead I issue an ATAPI reset (what now called a device reset?), because I don't want to write another or alter the current ata_command function and we need an atapi_reset function anyway. According spec, atapi devices SHOULD ONLY be reset via the atapi reset command (our ata driver doesn't follow this rule). The patch is for -stable. I hope it's not too difficult to port to -current. I have applied the patch manually to CURRENT, it helps nothing. :( Then I booted kernel without the patch, waited for a very long time to let ata code retry, finally it found the Sony 16X CD RW, but I can not mount it. It is always timeout. David Xu To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
At 2:07 AM +0100 2003/03/06, Philip Paeps wrote: Speaking of ndc, I think that's a BIND8-ism. Indeed, it is. With BIND-9, ndc won't even work -- Unix sockets aren't supported, and IP sockets are secured with crypto keys. Could the port be convinced to symlink it to rndc when set to replace the base, or would that confuse other things? Currently, I'm just aliasing it in my shell, but that seems a bit hackish :-) That could potentially be done, but keep in mind that there are some things that ndc can do that rndc can't -- ndc start being one of the big ones. -- Brad Knowles, [EMAIL PROTECTED] They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++): a C++(+++)$ UMBSHI$ P+++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+() DI+() D+(++) G+() e++ h--- r---(+++)* z(+++) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
USB makes system totally FUBAR
First off, please note that I had to use a serial console to get all the information in this message. Whenever the kernel panic'd, it locked my system hard. This isn't normally the case, but it was with this issue. I have a SanDisk Corporation(0x0781) ImageMate CompactFlash USB CF reader(0x0002). Lately, I've been having horrid problems with it under FreeBSD 5.0-CURRENT. I can only boot with it attached if it is empty (no CF card loaded). Otherwise, my boot process hangs. If I pull the CF reader from the USB port during the probe loop, my system panics. FreeBSD edgemaster.zombie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Tue Mar 4 20:30:35 CST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ EDGEMASTER i386 Here's what I got from the serial console: When connecting the CF reader without a CF card in it: uhub0: port error, restarting port 2 uhub0: port error, restarting port 2 umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2 umass0: Get Max Lun not supported (STALLED) da0 at umass-sim0 bus 0 target 0 lun 0 da0: SanDisk ImageMate II 1.30 Removable Direct Access SCSI-2 device da0: 1.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): Unretryable error Opened disk da0 - 6 Disconnecting the CF reader: umass0: at uhub0 port 2 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost device (da0:umass-sim0:0:0:0): removing device entry umass0: detached Connecting the CF reader WITH a CF card in it: uhub0: port error, restarting port 1 umass0: SanDisk Corporation ImageMate CompactFlash USB, rev 1.10/0.09, addr 2 umass0: Get Max Lun not supported (STALLED) umass0: BBB reset failed, STALLED can't re-use a leaf (minimum_cmd_size)! umass0: BBB reset failed, STALLED umass0: BBB reset failed, STALLED umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, TIMEOUT umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, TIMEOUT umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, TIMEOUT (da0:umass-sim0:0:0:0): got CAM status 0x4 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device umass0: BBB reset failed, TIMEOUT umass0: BBB bulk-in clear stall failed, TIMEOUT umass0: BBB bulk-out clear stall failed, TIMEOUT umass0: BBB reset failed, TIMEOUT *** LOOP *** Pulling the CF reader from the USB port, hoping to stop it: umass0: at uhub0 port 1 (addr 2) disconnected umass0: detached (null): BBB bulk-out clear stall failed, CANCELLED umass-sim:4:0:0:func_code 0x0901: Invalid target (target needed) panic: (null): Unknown state 1 Stack backtrace: backtrace(c0351b6d,c03be120,c04ec2c3,df9a3bbc,1) at backtrace+0x17 panic(c04ec2c3,0,1,c675a000,c04de1f9) at panic+0x96 umass_bbb_state(c72db900,c6d9c600,6,0,c72db93c) at umass_bbb_state+0x60c usb_transfer_complete(c72db900,2,c72db964,8,c70f9000) at usb_transfer_complete+0x12a uhci_abort_xfer(c72db900,6,df9a3c44,c04d1819,c72db900) at uhci_abort_xfer+0xb9 uhci_device_ctrl_abort(c72db900,c70f9000,df9a3c50,c04d1491,c70f9000) at uhci_device_ctrl_abort+0x19 usbd_ar_pipe(c70f9000,df9a3c64,c04d0164,c70f9000,c6e3da00) at usbd_ar_pipe+0x29 usbd_abort_pipe(c70f9000,c6e3da00,c6da8100,df9a3c80,c04d0bbd) at usbd_abort_pipe+0x11 usbd_kill_pipe(c70f9000,c01e12aa,c6da8100,1,c677dd30) at usbd_kill_pipe+0x14 usb_free_device(c6da8100,c6e3da00,c6723980,c6723980,3) at usb_free_device+0x1d usb_disconnect_port(c677dd30,c677da80,11,2,0) at usb_disconnect_port+0xda uhub_explore(c677db80,c6769660,df9a3d0c,c04ce7c8,c6769660) at uhub_explore+0x18e usb_discover(c6769660,0,5c,c04de214,1770) at usb_discover+0x35 usb_event_thread(c6769660,df9a3d48,c034fac6,35f,0) at usb_event_thread+0x68 fork_exit(c04ce760,c6769660,df9a3d48) at fork_exit+0xb2 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf9a3d7c, ebp = 0 --- syncing disks, buffers remaining... panic: bdwrite: buffer is
Re: Plea for base system trim
On Thu, 6 Mar 2003, Philip Paeps wrote: That way, both named and ndc see the same picture of the system, in and out of the chroot tree. Speaking of ndc, I think that's a BIND8-ism. Not _exactly_ true, but yes, ndc is what you use to manage BIND 8. All comparisons to tools that you may or may not use to manage future versions of BIND are apples and oranges. -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Plea for base system trim
On 2003-03-06 02:17:19 (+0100), Brad Knowles [EMAIL PROTECTED] wrote: At 2:07 AM +0100 2003/03/06, Philip Paeps wrote: Speaking of ndc, I think that's a BIND8-ism. Indeed, it is. With BIND-9, ndc won't even work I discovered that the unpleasant way. Typing ndc gave me a long list of socket errors and other general unhappiness. Even after quite a while, I still find myself forgetting the 'r' in ndc. Good I have an alias :-) Could the port be convinced to symlink it to rndc when set to replace the base, or would that confuse other things? Currently, I'm just aliasing it in my shell, but that seems a bit hackish :-) That could potentially be done, but keep in mind that there are some things that ndc can do that rndc can't -- ndc start being one of the big ones. Mmm, true. For all purposes, however, rndc is the ndc of BIND9, and I doubt I'm the only DNS-admin who's typed ndc so often it's become a nervous tic :-) I didn't realise the 'ndc start' bit though. Sounds a bit like a chicken/egg situation? Life's little existential mysteries, eh? - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. BOFH Excuse #329: Server depressed, needs Prozac To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
witness: nfs buf queue
Doing a kernel build over NFS on today's -current gives a pile of following error messages during the final link phase: Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 Acquiring lockmgr lock nfs with the following non-sleepablelocks held: exclusive sleep mutex buf queue lock r = 0 (0xc0427b60) locked @ ../../../kern/vfs_bio.c:2107 ... -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -O2 broke ppp NAT
On Wed, Mar 05, 2003 at 10:00:20PM +, Nuno Teixeira wrote: I rebuild everything with no CPUTYPE? and CFLAGS and ppp -nat is working again. I know that this isn't a important issue or bug because there are lots of warnings about gcc optimizations because the system may become unstable. If you can isolate exactly which lines of code are failing then it may help to identify the bug (either in the FreeBSD code, or in gcc). If you're not willing/able to do that, then you've already found the solution: I will not use extra optitimization on my buildsi anymore. A good lesson. :-) Kris pgp0.pgp Description: PGP signature
WITNESS panic in netinet/tcp_input.c
It seems like I'm being handed kernel panics on a platter today. I just got a WITNESS-related one in /usr/src/sys/netinet/tcp_input.c:2190. And actually, in the process of writing this message the first time, it happened again. I've since booted to an older kernel. The kernel this comes from is 5.0-CURRENT from Tue Mar 4 20:30:35 CST 2003. Soft updates appears to have turned my public PGP keyring file into a bunch of NULs too : I assume that is an artifact of the kernel panic. Script started on Wed Mar 5 19:51:06 2003 edgemaster# gdb -k /boot/kernel/kernel.debug vmcore.4 GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bwrite: buffer is not busy??? panic messages: --- panic: lock (sleep mutex) tcp not locked @ /usr/src/sys/netinet/tcp_input.c:2190 Stack backtrace: syncing disks, buffers remaining... panic: bwrite: buffer is not busy??? Uptime: 20m40s Dumping 1279 MB ata1: resetting devices .. done [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 16 32 48[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136 1152 1168 1184 1200 1216 1232 1248 1264 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 239 dumping++; (kgdb) bt full #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:239 No locals. #1 0xc01cd66a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:371 No locals. #2 0xc01cd8d3 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 td = (struct thread *) 0xc281aa50 bootopt = 260 newpanic = 0 buf = bwrite: buffer is not busy???\0ked @ /usr/src/sys/netinet/tcp_input.c:2190, '\0' repeats 182 times #3 0xc020e142 in bwrite (bp=0xd30a4778) at /usr/src/sys/kern/vfs_bio.c:795 oldflags = 537002148 newbp = (struct buf *) 0xc767d5b4 #4 0xc020fe5c in vfs_bio_awrite (bp=0xd30a4778) at /usr/src/sys/kern/vfs_bio.c:1692 i = 1 j = 0 lblkno = 0 vp = (struct vnode *) 0xc767d5b4 ncl = 0 nwritten = 16384 size = 16384 maxcl = 8 #5 0xc02c0dca in ffs_fsync (ap=0xdf976a00) at /usr/src/sys/ufs/ffs/ffs_vnops.c:257 vp = (struct vnode *) 0xc767d5b4 ip = (struct inode *) 0xd30a4778 bp = (struct buf *) 0xd30a4778 nbp = (struct buf *) 0x0 error = 0 wait = 0 passes = 4 skipmeta = 0 lbn = 1 #6 0xc02bff1e in ffs_sync (mp=0xc697a000, waitfor=2, cred=0xc2806e80, td=0xc037f6a0) at vnode_if.h:612 nvp = (struct vnode *) 0xc767d490 vp = (struct vnode *) 0xc767d5b4 devvp = (struct vnode *) 0xc767d5b4 ip = (struct inode *) 0x0 ump = (struct ufsmount *) 0xc699b300 fs = (struct fs *) 0xc697 error = 0 count = 0 wait = 0 lockreq = 18 allerror = 0 #7 0xc022261b in sync (td=0xc037f6a0, uap=0x0) at /usr/src/sys/kern/vfs_syscalls.c:138 mp = (struct mount *) 0xc697a000 nmp = (struct mount *) 0x0 asyncflag = 0 #8 0xc01cd29c in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:280 bp = (struct buf *) 0x0 iter = -1031689648 nbusy = -1031700352 pbusy = -1031689648 subiter = -1031700352 #9 0xc01cd8d3 in panic () at /usr/src/sys/kern/kern_shutdown.c:542 td = (struct thread *) 0xc281aa50 bootopt = 256 newpanic = 1 buf = bwrite: buffer is not busy???\0ked @ /usr/src/sys/netinet/tcp_input.c:2190, '\0' repeats 182 times #10 0xc01ee013 in witness_unlock (lock=0xc038f9cc, flags=8, file=0xc035a374 /usr/src/sys/netinet/tcp_input.c, line=2190) at /usr/src/sys/kern/subr_witness.c:951 lock_list = (struct lock_list_entry **) 0xc03e3540 instance = (struct lock_instance *) 0xc03e3554 class = (struct lock_class *) 0xc0384160 s = 1664 i = 0 j = -1070007860 #11 0xc01c4952 in _mtx_unlock_flags (m=0xc03e3554, opts=0, file=0xc038f9cc `A8À\a\2125À\a\2125À, line=-1069664960) at /usr/src/sys/kern/kern_mutex.c:357 No locals. #12 0xc0255ec9 in tcp_input (m=0xc038f9cc, off0=20) at /usr/src/sys/netinet/tcp_input.c:2324 th = (struct tcphdr *) 0xc34c1824 ip = (struct ip *) 0xc34c1810 ipov = (struct ipovly *)
Re: [PATCH 5.x] netns
Guys; I have to agree with Terry that the fixes for netns should be committed, and furthermore they should be MFC (using his first patch perhaps). It's a nightmare to try to rescue anything from the Attic, at least it would be nice to have it in better shape before killing it. The flame fest on removing it or not can go on ;). cheers, Pedro. __ Yahoo! Cellulari: loghi, suonerie, picture message per il tuo telefonino http://it.yahoo.com/mail_it/foot/?http://it.mobile.yahoo.com/index2002.html To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH 5.x] netns
On Wed, Mar 05, 2003 at 04:03:49AM -0800, Terry Lambert wrote: Peter Wemm wrote: Terry Lambert wrote: Here are two patches. The first fixes missing pieces in /sys/conf/files and /sys/conf/options, the second fixes all the files that need it in /sys/netns/. You seem to have posted the wrong patch. This is against 4.x, not -current, and this is [EMAIL PROTECTED] Here is a single patch vs. 5.x. I believe this makes it actually work. ^ huh? This is untested? Please apply this to the code, even if you are intent on putting working code in the Attic. Why keep it? You've just proven that even one with a desire has trouble determining if it works or not. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Mark Murray wrote: Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the fix. Only if some idiot breaks the API contract again. Whatever happened to you broke it, you fix it? Hopefully, the next time it happens, and something gets punted to the Attic, it will be code *you* care about, instead of code I care about. Then it will be *your* problem, and I can sit back and make smarmy postings. Guess what? This has already happened. I'm working on a fix. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Let' start wth the libalias/natd incremental checksum update code; the code is based on RFC1141, instead of RFC1624. As a result, it get updated incorrectly occasionally, because it's using two's complement instead of one's complement math. Per RFC1642: RFC 1141 yields an updated header checksum of -0 when it should be +0. This is because it assumed that one's complement has a distributive property, which does not hold when the result is 0 (see derivation of [Eqn. 2]). People see this as hands on FTP installs, etc., going through FreeBSD based NAT's. It's very obvious ad easy to repeat: 1)Put a printf in tcp_input.c that compalins when the checksum is incorect. 2)Do a CVSup from that machine through a FreeBSD NAT How long can this remain unfixed before the code is diked out, and the checksum is recalculated fully, instead? Terry, you sound rather foolish when you argue like this. This is semantic tomfoolery and off topic. End of thread. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Hi At 08:53 5/3/03, Terry Lambert wrote: [...] The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. The same is true for netipx (wc -l *.[ch] is almost identical). -- Bob Bishop +44 (0)118 977 4017 [EMAIL PROTECTED] fax +44 (0)118 989 4254 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
[no subject]
On the other hand, there's no compelling reason to dike it out, if it can be made to work. work == not just compiled, but QAed against known-working implementations and correctly documented. Have fun. Looking forward to the patches and logs. mcl To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
On Wed, 5 Mar 2003, Terry Lambert wrote: The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. And it will still be available. It'll just be available in the Attic. The fact that it will get more broken in the future because it's not being maintained in the tree is not terribly significant since it's already broken now. On the other hand, there's no compelling reason to dike it out, There is at least one, namely that it will make kernel code updates easier to do, and easier to test. if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. Your argument here is non sequitur because we still have large bases of users and developers that have and use this hardware. I retired a box with an original P90 f00f bug cpu not that long ago, for example. netns has neither freebsd users or developers, and hasn't for years. In any case, Peter pointed out that my patch was against -stable, not -current. I'm in the process of CVSup'ing new sources now, and will update the patch against -current, and post it, most likely tomorrow morning, if the CVSup doesn't complete in the next hour. I think that fixing the current brokeness is still useful, even if it gets axed. Putting it to bed with a full tummy will make future educational value of the code that much higher. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Juli Mallett wrote: * De: Terry Lambert [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] On the other hand, there's no compelling reason to dike it out, if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. I have a 486, lots of people have 486 PC 104 boards. I have a lot of ISA stuff. VLSI support would be equally obsolete. So would support for a Sequent SMP 386. We don't support them. We have at least one feature you demonstate over and over needs moved to the attic. I personally have two 4-port terminal servers that speak XNS. I'm pretty sure that others exist. The argument about IPX is just as simple is true. But it's not useful for educational purposes, because it collides with a protocol in common use; hacking it up isn't a good thing. The argument about Cisco's IOS not supporting it soon is irrelevent, until all the Cisco's on the net have their IOS image updated to the version that doesn't support it. It took about 3 years for the updates to get out there so IPv6 was usable, so we have at least 3 years. If you want to make this argument about orphan code, then make it about orphan code. If you want to make this argument about reduced FreeBSD size, then make it about reduced FreeBSD size. If you want to make it about failure to attract a maintainer, then do that. I can give you reasoned arguments why all of these are wrong, using historical examples from previous major code changes in the FreeBSD source tree. And here we see the source of my previous cynicism: The truth is that you are proving that this was never about the code does not even compile, and you are proving that this was never about no one is willing to maintain the code. If you go ahead and dike the code out, in the future, don't be disingenuous about your motives in doing so, and pretend that they are based on legitimate maintenance concerns, when they aren't. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re:
Mark Linimon wrote: On the other hand, there's no compelling reason to dike it out, if it can be made to work. work == not just compiled, but QAed against known-working implementations and correctly documented. Have fun. Looking forward to the patches and logs. Just to be perfectly clear on what you are saying here: Diking things out is OK, if there's no proven QA and/or no documentation, or the documentation which exists is not correct, right? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Doug Barton wrote: On Wed, 5 Mar 2003, Terry Lambert wrote: The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. And it will still be available. It'll just be available in the Attic. The fact that it will get more broken in the future because it's not being maintained in the tree is not terribly significant since it's already broken now. Why don't we let me sumbit patches, apply the things, and *then* dike the code out, if that's your reasoning? On the other hand, there's no compelling reason to dike it out, There is at least one, namely that it will make kernel code updates easier to do, and easier to test. And here people were telling me I was wrong for cynically assuming that the reason people diked out so much code in the past year was because they wanted to perform kernel code updates, without having to maintain all the code they would be touching with those updates... if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. Your argument here is non sequitur because we still have large bases of users and developers that have and use this hardware. I retired a box with an original P90 f00f bug cpu not that long ago, for example. netns has neither freebsd users or developers, and hasn't for years. And I have two XNS terminalservers, and there are people on this list with Apollo equipment. Your point was again? In any case, Peter pointed out that my patch was against -stable, not -current. I'm in the process of CVSup'ing new sources now, and will update the patch against -current, and post it, most likely tomorrow morning, if the CVSup doesn't complete in the next hour. I think that fixing the current brokeness is still useful, even if it gets axed. Putting it to bed with a full tummy will make future educational value of the code that much higher. I suggested that before. People are telling me they won't apply the patches before they murder the code. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
On Wed, 5 Mar 2003, Terry Lambert wrote: If you want to make it about failure to attract a maintainer, then do that. Actually several people have made this argument, along with the corollary failure to attract a userbase. -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
It took about 3 years for the updates to get out there so IPv6 was usable i have yet to see a cisco ios image supporting ipv6 that was usable in production environment. and i have tried hard. but i will admit to not having seen apollo networking for over a decade. but i probably have not been looking very widely. seems to me that one useful question is whether the netns code being there non-trivially complicates maintenance and/or reliability of other code, and can i compile or module it out if the bits it occupies really bothers me? randy To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Doug Barton wrote: On Wed, 5 Mar 2003, Terry Lambert wrote: If you want to make it about failure to attract a maintainer, then do that. Actually several people have made this argument, along with the corollary failure to attract a userbase. I would claim that non-working code *repelled* the userbase, just as all the packet radio people went to Linux when the ISODE code was murdered and X.25 went away, the same way we are talking about doing to the XNS code now. If your system can't do something, then *of course* you are n'tgoing to attract user who want to do that something: they will go to systems that aren't incapable of doing what they want. I would claim that the failure to attract a maintainer was a result of too stringent control of commit priviledges. There is code lying fallow in FreeBSD now which has no maintainer, for lack of commit priviledges for people willing to maintain the code (and no, I am not making a case for myself here). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
On Wed, 5 Mar 2003, Terry Lambert wrote: Doug Barton wrote: On Wed, 5 Mar 2003, Terry Lambert wrote: The code is still useful as a simple implementation, much more easily understood by the student than the current TCP/IP stack, for certain. And it will still be available. It'll just be available in the Attic. The fact that it will get more broken in the future because it's not being maintained in the tree is not terribly significant since it's already broken now. Why don't we let me sumbit patches, apply the things, and *then* dike the code out, if that's your reasoning? We should. If no one else wants to do it, I'll be glad to. I can raise my kernel commit percentage a whole order of magnitude! (up to 0.0001%) On the other hand, there's no compelling reason to dike it out, There is at least one, namely that it will make kernel code updates easier to do, and easier to test. And here people were telling me I was wrong for cynically assuming that the reason people diked out so much code in the past year was because they wanted to perform kernel code updates, without having to maintain all the code they would be touching with those updates... I think that's definitely part of the motivation, I just think you're wrong to be cynical about it. :) There is no reason not to cut broken, unused code when it will always be available in CVS if someone comes along to make it useful again. if it can be made to work. I would argue that ISA support is more or less just as obsolete, as is 486 support, as is the F00F bug workaround, as is ... a lot of code that's still there. Your argument here is non sequitur because we still have large bases of users and developers that have and use this hardware. I retired a box with an original P90 f00f bug cpu not that long ago, for example. netns has neither freebsd users or developers, and hasn't for years. And I have two XNS terminalservers, and there are people on this list with Apollo equipment. Your point was again? My point is that we do not, and can not have any user base for the code as it exists, and we could not have for years because it doesn't work. The fact that there may be N users of netns in the universe doesn't affect the brokeness of our code as it has existed in recent history. Doug -- This .signature sanitized for your protection To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
* De: Mark Murray [EMAIL PROTECTED] [ Data: 2003-03-05 ] [ Subjecte: Re: Removal of netns - politically correct version ] Terry Lambert writes: Peter Wemm wrote: Terry Lambert wrote: Is there a compelling reason for removing this working code to the Attic? Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? compile-only would be a good state to leave the code in the attic. -- juli mallett. email: [EMAIL PROTECTED]; aim: bsdflata; efnet: juli; To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
i have yet to see a cisco ios image supporting ipv6 that was usable in production environment. and i have tried hard. This is getting OT but on the subject of repelling users, they´re probably trying hard to repel their users to the vendor J boxen. but i will admit to not having seen apollo networking for over a decade. but i probably have not been looking very widely. I´ve made a sighting in 1996 if I remember correctly. For their sake, I hope that´s gone now. seems to me that one useful question is whether the netns code being there non-trivially complicates maintenance and/or reliability of other code, and can i compile or module it out if the bits it occupies really bothers me? This is probably the right question. Pete To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Juli Mallett writes: This crap is *s* trivial to fix, it's easier to fix than to watch you guys bitch about it not being fixable. Will it be runnable (as in tested), rather than a compile-only fix? compile-only would be a good state to leave the code in the attic. Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the fix. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Mark Murray wrote: Terry Lambert writes: Peter Wemm wrote: Terry: will you please check your facts? It takes around 30 seconds to find out that it doesn't even compile. [ ... lots of trivial to fix warnings and errors ... ] Tell you what, I'll fix these and post a patch. Will that make you guys happy? Will it be runnable (as in tested), rather than a compile-only fix? Is tested a requirement fo code to be committed or to have it stay in the tree? Be careful of your answer, unless you are willing to remove all code that does not meet that criteria... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Terry Lambert writes: Mark Murray wrote: Will it be runnable (as in tested), rather than a compile-only fix? Is tested a requirement fo code to be committed or to have it stay in the tree? Both. Be careful of your answer, unless you are willing to remove all code that does not meet that criteria... Be careful of your interpretation of my answer. State _all_ your premises, and be careful not to use any undeclared ones. Do not hold me to any premise that I have not agreed to. All broken code needs to be fixed XOR removed. All fixes need to be tested. All code in the tree needs to be tested often to ensure that it is not broken. M -- Mark Murray iumop ap!sdn w,I idlaH To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH 5.x] netns
Peter Wemm wrote:
Terry Lambert wrote:
Here are two patches. The first fixes missing pieces in /sys/conf/files
and /sys/conf/options, the second fixes all the files that need it in
/sys/netns/.
You seem to have posted the wrong patch.
This is against 4.x, not -current, and this is [EMAIL PROTECTED]
Here is a single patch vs. 5.x.
I believe this makes it actually work. I have addressed all
the protosw issues in this patch.
Please apply this to the code, even if you are intent on putting
working code in the Attic.
Thanks,
-- TerryIndex: conf/files
===
RCS file: /cvs/src/sys/conf/files,v
retrieving revision 1.765
diff -c -r1.765 files
*** conf/files 4 Mar 2003 23:19:55 - 1.765
--- conf/files 5 Mar 2003 06:03:11 -
***
*** 1429,1434
--- 1429,1435
netns/ns_output.c optional ns
netns/ns_pcb.coptional ns
netns/ns_proto.c optional ns
+ netns/ns_cksum.c optional ns
netns/spp_debug.c optional ns
netns/spp_usrreq.coptional ns
netsmb/smb_conn.c optional netsmb
Index: netns/idp_usrreq.c
===
RCS file: /cvs/src/sys/netns/idp_usrreq.c,v
retrieving revision 1.15
diff -c -r1.15 idp_usrreq.c
*** netns/idp_usrreq.c 19 Feb 2003 05:47:37 - 1.15
--- netns/idp_usrreq.c 5 Mar 2003 08:04:20 -
***
*** 54,59
--- 54,63
#include netns/idp_var.h
#include netns/ns_error.h
+ extern int idpcksum; /* from ns_input.c */
+ extern long ns_pexseq;/* from ns_input.c */
+ extern struct nspcb nsrawpcb; /* from ns_input.c */
+
/*
* IDP protocol implementation.
*/
***
*** 63,72
/*
* This may also be called for raw listeners.
*/
! idp_input(m, nsp)
struct mbuf *m;
! register struct nspcb *nsp;
{
register struct idp *idp = mtod(m, struct idp *);
struct ifnet *ifp = m-m_pkthdr.rcvif;
--- 67,78
/*
* This may also be called for raw listeners.
*/
! void
! idp_input(m, nsp0)
struct mbuf *m;
! int nsp0; /* XXX offset */
{
+ register struct nspcb *nsp = ns_pcblookupm(m);
register struct idp *idp = mtod(m, struct idp *);
struct ifnet *ifp = m-m_pkthdr.rcvif;
***
*** 79,92
idp_ns.sns_addr = idp-idp_sna;
if (ns_neteqnn(idp-idp_sna.x_net, ns_zeronet) ifp) {
register struct ifaddr *ifa;
! for (ifa = ifp-if_addrlist; ifa; ifa = ifa-ifa_next) {
if (ifa-ifa_addr-sa_family == AF_NS) {
idp_ns.sns_addr.x_net =
IA_SNS(ifa)-sns_addr.x_net;
break;
}
! }
}
nsp-nsp_rpt = idp-idp_pt;
if ( ! (nsp-nsp_flags NSP_RAWIN) ) {
--- 85,100
idp_ns.sns_addr = idp-idp_sna;
if (ns_neteqnn(idp-idp_sna.x_net, ns_zeronet) ifp) {
register struct ifaddr *ifa;
+ int s;
! s = splimp();
! TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
if (ifa-ifa_addr-sa_family == AF_NS) {
idp_ns.sns_addr.x_net =
IA_SNS(ifa)-sns_addr.x_net;
break;
}
! splx(s);
}
nsp-nsp_rpt = idp-idp_pt;
if ( ! (nsp-nsp_flags NSP_RAWIN) ) {
***
*** 103,108
--- 111,117
m_freem(m);
}
+ void
idp_abort(nsp)
struct nspcb *nsp;
{
***
*** 134,153
so-so_error = errno;
ns_pcbdisconnect(nsp);
soisdisconnected(so);
}
int noIdpRoute;
! idp_output(nsp, m0)
! struct nspcb *nsp;
struct mbuf *m0;
{
! register struct mbuf *m;
register struct idp *idp;
- register struct socket *so;
register int len;
register struct route *ro;
! struct mbuf *mprev;
! extern int idpcksum;
len = m_length(m0, mprev);
/*
--- 143,164
so-so_error = errno;
ns_pcbdisconnect(nsp);
soisdisconnected(so);
+ return(NULL); /* XXX */
}
int noIdpRoute;
!
! int
! idp_output(m0, so)
struct mbuf *m0;
+ struct socket *so;
{
! struct nspcb *nsp = sotonspcb(so);
! struct mbuf *m;
register struct idp *idp;
register int len;
register struct route *ro;
! struct mbuf *mprev = NULL;
len = m_length(m0, mprev);
/*
***
*** 204,210
/*
* Output datagram.
*/
- so = nsp-nsp_socket;
if (so-so_options SO_DONTROUTE)
return (ns_output(m, (struct route *)0,
Re: Removal of netns - politically correct version
Petri Helenius wrote: seems to me that one useful question is whether the netns code being there non-trivially complicates maintenance and/or reliability of other code, and can i compile or module it out if the bits it occupies really bothers me? This is probably the right question. As people keep pointing out, the code has been disabled since 1996, so it doesn't complicate maintenance, because maintenance hasn't been being done, even though it's trivially easy. What pisses me off about this is that people have been breaking API's out from under code, in such a way that no one who is not highly domain knowledgable can unbreak the code that they did not maintain. An API is a contract between pieces of code. If you break that contract, then you are responsible for fixing every piece of code that uses the contract. If people actually did this (they *don't*), THEN leaving the code in would complicate maintenance. Please apply the patches I have posted to the list for netns. Thanks, -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Removal of netns - politically correct version
Mark Murray wrote: Only if it kills this _really_ dumb debate. In time, it will no longer compile, and then the situation will be the same as just punting to the Attic without the fix. Only if some idiot breaks the API contract again. Whatever happened to you broke it, you fix it? Hopefully, the next time it happens, and something gets punted to the Attic, it will be code *you* care about, instead of code I care about. Then it will be *your* problem, and I can sit back and make smarmy postings. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
