Re: fxp0 device timeout on 5.0-RELEASE
Am Do, 2003-01-30 um 12.41 schrieb Sergey A. Osokin: > > 3) Put hw.pci.allow_unsupported_io_range="1" into your > /boot/loader.conf.local Thanks, that did the trick. Could we, maybe, add a little note about this to the release notes or errata? Or better yet, how about a big fat warning message if the kernel probes a device at an unsupported address while hw.pci.allow_unsupported_io_range==0? -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Wed, Jan 29, 2003 at 10:35:40PM -0500, Garance A Drosihn wrote: > At 9:18 PM +0200 1/29/03, Sheldon Hearn wrote: > >Can anyone think of a good way to implement an installworld / > >installkernel seat-belt for source upgrades from stable to current? > > > >What I'm looking for is a way for installworld and installkernel > >in the current source to look for some signature in the target > >filesystem that suggests that a stable world is about to be > >upgraded to current. > > How about requiring the user to touch some file in / or /boot which > indicates the branch-tag that's acceptable for installworlds? Then > you just need to propagate the tag from the 'cvs co' stage to some > file under /usr/src (such as /usr/src/CVS/Tag ). > That's exactly the case when upgrading from -stable to -current. Installkernel should be the first thing to install, and it will complain with: : You must set up a /boot/device.hints file first. > So, maybe compare /usr/src/CVS/Tag to /boot/BRANCH_TAG, where the > second file has to be typed in by the user, by hand. Eh, maybe > /boot isn't the right place for it. Well, maybe /.branch_tag > > >[1] Guess who just trashed a stable installation for the 3rd time > >in 3 years today? > > Well, I almost would have done the same thing in my latest 4.7 > install, but when I cd'ed into sys/i386/conf I thought it was > odd that there was a GENERIC.hints file sitting there... If > it wasn't for my desire to compile an SMP kernel instead of > GENERIC, I might not have noticed until it was too late!! > We could expand the ``installcheck'' target in Makefile.inc1 to ask the user if he actually wants to upgrade from `uname -r` (the running kernel) to what appears to be an argument to "cvs update" in the ``update'' target in the same makefile (-A for HEAD, and RELENG_* otherwise). Running uname(1) from ${.OBJDIR} is a bad idea as it may not be runnable at all. Cheers, -- 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 msg51330/pgp0.pgp Description: PGP signature
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 11:33:16PM -0500, Mike Makonnen wrote: > On Thu, 30 Jan 2003 20:05:06 -0800 > David Schultz <[EMAIL PROTECTED]> wrote: > > > > > That's a great answer...to a different question. ;-) > > > > Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on > the repository remotely, so you don't need to have the files checked out localy. > Er, rlog is just a synonym for log. Cheers, -- 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 msg51331/pgp0.pgp Description: PGP signature
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 09:58:15PM -0800, David Schultz wrote: > Thus spake Christopher Vance <[EMAIL PROTECTED]>: > > On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote: > > : On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote: > > : > Thus spake Steve Kargl <[EMAIL PROTECTED]>: > > : > > On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote: > > : > > > OT: Is there a good way to get the CVS metadata in /usr/src and > > : > > > /usr/ports without transferring the entire source tree over the > > : > > > network? On some machines, I'd like to be able to do a CVS > > : > > > {diff,log,update} now and then, but I don't have the disk space > > : > > > for the entire repository. I usually end up blowing away /usr/src > > : > > > and fetching a new copy from a CVS server, but I'm sure this is > > : > > > far from ideal for the people who pay for that server's bandwidth. > > : > > > > > : > > > > : > > anoncvs > > : > > > > : > > See the handbook for info. > > : > > > : > That's a great answer...to a different question. ;-) > > : > > : It's the correct answer. I assumed that you knew > > : how to use cvs. > > > > cvsup gets me everything I need to track and compile both current and > > stable. > > > > I don't want to be forced into using cvs when there's a better tool > > available (for some definition of better). I get paid to use cvs at > > work, and that's how I know to choose something else... > > > > For a while, I used to grab the whole repo (with cvsup), and used cvs > > to get current and stable out of it, but now I consider that a waste > > of space/time, and have reverted to just using cvsup to get the tags I > > want. > > > > I'm not a FreeBSD developer, and very rarely (just a handful of times) > > have had to modify existing stuff to do what I want, so I don't need > > my own repo to commit to. With that, disappers any need to use cvs. > > > > Perhaps you can explain why cvsup is the wrong answer... > > I don't know about Steve, but cvsup is the wrong answer for me > because it's a mirroring tool and not a version control tool. > Among the things I would like to do are: > > - Update to a specific version of a specific file from the > repository. > > - Generate a diff between two revisions in the repository, > or between a version in the repository and some local > patches of my own. > > - View logs for particular files. > > I asked the question in hopes that there would be some neat > feature of cvsup that mocked up some CVS metadata for me, but > since nobody has mentioned any such thing, I guess I'm out of > luck. Mirroring the entire repository is not an option on > machines with less than 6 GB of spare disk.[1] Transferring the > entire source tree over the network via anoncvs is suboptimal when > all I really want is a few kilobytes of 'CVS' subdirectories. > But I guess it will have to do for now. > > > [1] When the system is an aging dual PPro or 200MHz Alpha using > SCSI, buying new drives is not practical. > Well then learn how to use anoncvs? Cheers, -- 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 msg51332/pgp0.pgp Description: PGP signature
Re: fxp0 device timeout on 5.0-RELEASE
On Fri, Jan 31, 2003 at 09:32:07AM +0100, Georg-W. Koltermann wrote: > Am Do, 2003-01-30 um 12.41 schrieb Sergey A. Osokin: > > > > 3) Put hw.pci.allow_unsupported_io_range="1" into your > > /boot/loader.conf.local > > Thanks, that did the trick. > > Could we, maybe, add a little note about this to the release notes or > errata? Or better yet, how about a big fat warning message if the > kernel probes a device at an unsupported address while > hw.pci.allow_unsupported_io_range==0? Yes, I send list of questions/answers about this problem to doc@. Still no answer from. Anyway list avaliable from my home page: http://ozz.pp.ru/eag.txt -- Rgdz,/"\ ASCII RIBBON CAMPAIGN Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL http://ozz.pp.ru/ X AND NEWS / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
5.0-RELEASE ports.tgz file missing?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I heard from several friends who did FTP installs of 5.0-RELEASE, that the installer was unable to install the ports collection. So I checked the various FTP sites, and to my amazement I couldn't find the ports.tgz file on any of them! See for example: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.0-RELEASE/ports/ ftp://ftp.nl.freebsd.org/pub/FreeBSD/releases/i386/5.0-RELEASE/ports/ or any other FreeBSD mirror sites. It is also the case for other architectures. However, on the 5.0-RELEASE i386 install CD I have here, there is such a ports directory, with a ports.tgz file (and accompanying CHECKSUM.MD5 and install.sh files). Is this a deliberate omission on the FTP servers? Cheers, - -- Dimitry Andric <[EMAIL PROTECTED]> PGP Key: http://www.xs4all.nl/~dim/dim.asc Fingerprint: 7AB462D2CE35FC6D42394FCDB05EA30A2E2096A3 Lbh whfg ivbyngrq gur QZPN naq jvyy or cebfrphgrq -BEGIN PGP SIGNATURE- Version: 6.5.8ckt http://www.ipgpp.com/ Comment: http://duncan.gn.apc.org/stoa_cover.htm iQA/AwUBPjjeELBeowouIJajEQImXgCgrDTtvOu1EUBgJj/nzKmIz2E9/OkAn0h4 DsyEcnU3YAtJ5P2yhwXUQ5Kf =5aHf -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fxp0 device timeout on 5.0-RELEASE
On Fri, 31 Jan 2003 12:14:29 +0300 "Sergey A. Osokin" <[EMAIL PROTECTED]> wrote: > On Fri, Jan 31, 2003 at 09:32:07AM +0100, Georg-W. Koltermann wrote: > > Am Do, 2003-01-30 um 12.41 schrieb Sergey A. Osokin: > > > > > > 3) Put hw.pci.allow_unsupported_io_range="1" into your > > > /boot/loader.conf.local > > > > Thanks, that did the trick. > > > > Could we, maybe, add a little note about this to the release notes > > or errata? Or better yet, how about a big fat warning message if > > the kernel probes a device at an unsupported address while > > hw.pci.allow_unsupported_io_range==0? > > Yes, I send list of questions/answers about this problem to doc@. > Still no answer from. Anyway list avaliable from my home page: > http://ozz.pp.ru/eag.txt > > -- > > Rgdz,/"\ ASCII RIBBON CAMPAIGN > Sergey Osokin aka oZZ, \ /AGAINST HTML MAIL > http://ozz.pp.ru/ X AND NEWS > / \ I was actually adding something when this email came into my mailbox. Sorry for not picking up on this before. -- Tom Rhodes To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0-RELEASE ports.tgz file missing?
Dimitry Andric wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I heard from several friends who did FTP installs of 5.0-RELEASE, that the installer was unable to install the ports collection. So I checked the various FTP sites, and to my amazement I couldn't find the ports.tgz file on any of them! See for example: ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.0-RELEASE/ports/ ftp://ftp.nl.freebsd.org/pub/FreeBSD/releases/i386/5.0-RELEASE/ports/ or any other FreeBSD mirror sites. It is also the case for other architectures. However, on the 5.0-RELEASE i386 install CD I have here, there is such a ports directory, with a ports.tgz file (and accompanying CHECKSUM.MD5 and install.sh files). Is this a deliberate omission on the FTP servers? Cheers, - -- Fixed on ftp-master, so it should work it's way out to the mirrors over the next few days. I'm not sure if this is an accidental or intended breakage of the release scripts, but many previous releases on FreeBSD have the ports directory in the FTP distro. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: copy extended attributes
I'm starting to have a bad feeling about mergemaster and /etc's full of acl and mac labels... Robert Watson wrote: I have local patches submitted by Chris Faulhaber to copy ACLs when a file is copied (or moved between file systems) that I've been meaning to finish testing and merge. Likewise, for gzip, bzip, and others when a file is replaced. This wouldn't address the general issue of copying extended attributes, but is a necessary step. Presumably if we did extend cp, et al, to copy EA's, they should explicitly copy only user namespace EAs, not system EAs. There's been some recent e-mail on the Linux side about interfaces to copy ACLs from one file to another, but I haven't had a chance to review those changes as yet to see whether we should pick them up. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] There once was a jolly old bloke Who picked up a girl for a poke. He took down her pants, Fucked her into a trance, And then shit into her shoe for a joke. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Cisco vpnclient
Cisco is offering a VPN client for Linux. I wonder if it would be possible to run this under FreeBSD. An extra linux kernel module is being built. Is this already the 'ruled out'? If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x beside my FreeBSD gateway. Would it be possible to use NAT to extend the VPN (I only have one dedicated fixed IP on the gateway). Excuse if this is not exactly on target of -current. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Profiling kills -current?
On Thu, Jan 30, 2003 at 04:17:39PM -0500, Robert Watson wrote: > Looks like recent commits may have broken profiling of user applications; > or rather, it's also causing the kernel to crash. I suspect (but have not > confirmed) it was the recent KSE commit. This commit should have fixed the problem causing the system to lock up when profiling was used. A quick check shows that it's generating reasonable results now, but I believe that there are other profiling bugs in -current. == tjr 2003/01/31 03:22:32 PST Modified files: sys/kern subr_trap.c Log: Use a local variable to store the number of ticks that elapsed in kernel mode instead of (unintentionally) using the global `ticks'. This error completely broke profiling. Revision ChangesPath 1.241 +3 -2 src/sys/kern/subr_trap.c == Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Jan 31 03:09:35 PST 2003 -- >>> Kernel build for GENERIC completed on Fri Jan 31 03:40:44 PST 2003 -- >>> Kernel build for LINT started on Fri Jan 31 03:40:45 PST 2003 -- ===> vinum "Makefile", line 4443: warning: duplicate script for target "geom_bsd.o" ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and is not compiled with LINT" /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning "The meteor driver is broken and is not compiled with LINT" /h/des/src/sys/pci/simos.c:30:2: warning: #warning "The simos driver is broken and is not compiled with LINT" /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_open': /h/des/src/sys/dev/gfb/gfb_pci.c:268: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:268: (Each undeclared identifier is reported only once /h/des/src/sys/dev/gfb/gfb_pci.c:268: for each function it appears in.) cc1: warnings being treated as errors /h/des/src/sys/dev/gfb/gfb_pci.c:275: warning: passing arg 1 of `genfbopen' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_close': /h/des/src/sys/dev/gfb/gfb_pci.c:284: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:285: warning: passing arg 1 of `genfbclose' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_read': /h/des/src/sys/dev/gfb/gfb_pci.c:293: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:294: warning: passing arg 1 of `genfbread' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_write': /h/des/src/sys/dev/gfb/gfb_pci.c:302: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:303: warning: passing arg 1 of `genfbwrite' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_ioctl': /h/des/src/sys/dev/gfb/gfb_pci.c:311: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:312: warning: passing arg 1 of `genfbioctl' from incompatible pointer type /h/des/src/sys/dev/gfb/gfb_pci.c: In function `pcigfb_mmap': /h/des/src/sys/dev/gfb/gfb_pci.c:320: `gfb_devclass' undeclared (first use in this function) /h/des/src/sys/dev/gfb/gfb_pci.c:321: warning: passing arg 1 of `genfbmmap' from incompatible pointer type *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.7-amd cannot mount exports from 5.0-RELEASE
Am Dienstag, 28. Januar 2003 21:52 schrieb Martin Blapp: > Hi, > > > Can this please be committed to or at least prepared as a patch for > > RELENG_5_0? I myself consider fixing automount access to 5.0-RELEASE nfs > > Feel free to add this patch: > > http://people.freebsd.org/~mbr/patches/committed/patch-rpc_oldreply.diff I'm sorry to have to bother you further, but this patch does not solve the problem completely. Amd works partially now, but I still get 'mountd rpc failed: RPC: Unable to receive' errors when I try to access /host// (nfsd on hostname exports / -alldirs,/usr -alldirs,/var -alldirs) and I can only access the / export. /host//usr or /host//var, where is the ip-address of the same machine as above, works as expected. -- Regards, Michael Nottebrock To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI kernel: no ata0 / no ide disks
Hi everyone, I finally got 5.0 of last week on my Tosh. Libretto 110ct running. Took me several days of headache and bootstrap problems, nfs mount and chroot finally solved my problems. (My laptop is a multiboot box with a 4.7 FBSD as well so I could mount the filesystem dedicated to the 5.0 system. I cast a naked 5.0 install onto my other box to do the chrooted kernel/world compiling) Currently I still have two serious problems with my 5.0 kernel, which is in one case GENERIC itself and in the other basically GENERIC again, except I commented out SCSI and USB stuff, uncommented several debugging opts (I knew I would be running into trouble some time...) and only cpu I586_CPU of the cpu lines. I state both problems here since I think they could be related (but probably are not). Problem 1) occurred with the GENERIC kernel, and as well with the new kernel when I >unset acpi_load in the final boot stage (the aprop. module probably just didn't exist prior installation of the custom kernel for some reason, so this all is not about switching the kernel). The symptom is that booting seems to hang (it turned out to be some kind of timeout of 5mins or so) at device probing time right after vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Booting -v showed that this delay happens in function isa_probe_pnp_children (could as well be isa_pnp_probe_children or so). When probing continues, the next five lines are of the kind unknown: can't assign resources (port) where one line has (irq) instead of (port). Sorry I have no means of appending dmesg at this moment. So, it works, but booting means making coffee in between. Here some device topology of this setup that might be interesting for problem 2: ad0 at ata0-master, ata0 on isa0 on motherboard. pci0 on pcib0 at pcibus 0 on motherboard. Problem 2) occurred when the acpi module was loaded: the kernel found no disks! The words 'isa' and 'ata' do not appear on the screen, but now my pci topology is pci0 on pcib0 on acpi0 on motherboard. acpi0 is (spaces exactly as on screen) I'm new to acpi and not very good in hardware, so this is really confusing to me. I cannot tell in what way this topology is normal or abnormal, but I would like to use both acpi and my disk! Another thing confuses me, maybe someone can give me some enlightenment: Rebooting without acpi, I noticed that syslogd took long to start up, together with lots of disk activity. dmesg showed the boot messages from all previous boots (which probably syslogd spooled from somewhere, which would explain the long startup and disk light), including the failed boots with acpi support. Now, in these latter cases my kernel saw no disk, so where did the information go that magically appeared later in my dmesg? This is a riddle to me! I would appreciate if someone could shed some light on this. If you need more info (dmesg's out e.g.) drop me a mail at [EMAIL PROTECTED] and I will post it to -current. Cheers, Thomas To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
>Date: Thu, 30 Jan 2003 21:58:15 -0800 >From: David Schultz <[EMAIL PROTECTED]> >I asked the question in hopes that there would be some neat >feature of cvsup that mocked up some CVS metadata for me, but >since nobody has mentioned any such thing, I guess I'm out of >luck. Mirroring the entire repository is not an option on >machines with less than 6 GB of spare disk.[1]... In the interest of providing empirical data, since this thread is being archived and someone might see the above and come to the conclusion that 6 GB of space is required for a full mirror of the CVS repository, I offer: freebeast(4.7-S)[1] cd /cvs freebeast(4.7-S)[2] du -ks . 1649982 . freebeast(4.7-S)[3] cd /usr/src freebeast(4.7-S)[4] !2 du -ks . 321999 . freebeast(4.7-S)[5] That's a little over 1.6 GB for the CVS repo itself, plus <350 MB for the /usr/src working directory. (I do have a little bit of extra stuff in the CVS repository for local things, but it isn't significant, and certainly doesn't change the point, which is that about 2 GB appears to be adequate at this time.) > >[1] When the system is an aging dual PPro or 200MHz Alpha using >SCSI, buying new drives is not practical. Given the price of hardware, it might be worth considering cobbling up a separate box for the purpose. You may have done this, and decided that it's not worth the cost, or is otherwise inappropriate or ineffective. That's fine: it's your problem and your resources, so how you choose to allocate them is (and should be) your decision. But any solution will cost some resources. For me, keeping a local mirror of the CVS repository works well enough that I'm rather surprised that it isn't done by more folks. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I have no confidence in results obtained through the use of Microsoft products. david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I have no confidence in results obtained through the use of Microsoft products. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: last KSE changes
On 2003-01-28 11:24:41 (-0800), Julian Elischer <[EMAIL PROTECTED]> wrote: > The rumour mill has been running wild on this but **AS FAR AS I KNOW** the > breakages have been fixed, since no-one has told me directl of any current > breakages. If you have any breakage from this commit, PLEASE TELL ME! Is this the sort of breakage you were expecting: On an Alpha: | linking kernel | init_main.o: In function `proc0_init': | init_main.o(.text+0x428): undefined reference to `kse0_sched' | init_main.o(.text+0x434): undefined reference to `ksegrp0_sched' | init_main.o(.text+0x440): undefined reference to `proc0_sched' | init_main.o(.text+0x44c): undefined reference to `thread0_sched' | *** Error code 1 | | Stop in /usr/obj/usr/src/sys/PROSPERINA. | *** Error code 1 | | Stop in /usr/src. | *** Error code 1 | | Stop in /usr/src. On an i386: | linking kernel | init_main.o: In function `proc0_init': | init_main.o(.text+0x2b9): undefined reference to `kse0_sched' | init_main.o(.text+0x2c3): undefined reference to `ksegrp0_sched' | init_main.o(.text+0x2cd): undefined reference to `proc0_sched' | init_main.o(.text+0x2d7): undefined reference to `thread0_sched' | kern_clock.o: In function `statclock_process': | kern_clock.o(.text+0x704): undefined reference to `sched_clock' | kern_condvar.o: In function `cv_wait': | kern_condvar.o(.text+0x18f): undefined reference to `sched_sleep' | kern_condvar.o: In function `cv_wait_sig': | kern_condvar.o(.text+0x3fa): undefined reference to `sched_sleep' | kern_condvar.o: In function `cv_timedwait': | kern_condvar.o(.text+0x738): undefined reference to `sched_sleep' | kern_condvar.o: In function `cv_timedwait_sig': | kern_condvar.o(.text+0xa3a): undefined reference to `sched_sleep' | kern_exit.o: In function `wait1': | kern_exit.o(.text+0x14aa): undefined reference to `sched_exit' | kern_fork.o: In function `fork1': | kern_fork.o(.text+0xece): undefined reference to `sched_fork' | kern_idle.o: In function `idle_proc': | kern_idle.o(.text+0xb6): undefined reference to `sched_runnable' | kern_mutex.o: In function `propagate_priority': | kern_mutex.o(.text+0x7a): undefined reference to `sched_prio' | kern_proc.o: In function `procinit': | kern_proc.o(.text+0xe9): undefined reference to `sched_sizeof_proc' | kern_proc.o: In function `fill_kinfo_proc': | kern_proc.o(.text+0x149b): undefined reference to `sched_pctcpu' | kern_resource.o: In function `donice': | kern_resource.o(.text+0x9f8): undefined reference to `sched_nice' | kern_subr.o: In function `uio_yield': | kern_subr.o(.text+0x59e): undefined reference to `sched_prio' | kern_switch.o: In function `choosethread': | kern_switch.o(.text+0x9): undefined reference to `sched_choose' | kern_switch.o: In function `kse_reassign': | kern_switch.o(.text+0x147): undefined reference to `sched_add' | kern_switch.o: In function `adjustrunqueue': | kern_switch.o(.text+0x1dc): undefined reference to `sched_rem' | kern_switch.o(.text+0x1e4): undefined reference to `sched_add' | kern_switch.o(.text+0x218): undefined reference to `sched_rem' | kern_switch.o: In function `setrunqueue': | kern_switch.o(.text+0x313): undefined reference to `sched_rem' | kern_switch.o(.text+0x3cd): undefined reference to `sched_add' | kern_synch.o: In function `msleep': | kern_synch.o(.text+0x43b): undefined reference to `sched_sleep' | kern_synch.o: In function `mi_switch': | kern_synch.o(.text+0xc4a): undefined reference to `sched_switchout' | kern_synch.o(.text+0xc66): undefined reference to `sched_switchin' | kern_synch.o: In function `setrunnable': | kern_synch.o(.text+0xd6b): undefined reference to `sched_wakeup' | kern_synch.o: In function `yield': | kern_synch.o(.text+0xfb9): undefined reference to `sched_prio' | kern_thread.o: In function `threadinit': | kern_thread.o(.text+0x1287): undefined reference to `sched_sizeof_thread' | kern_thread.o(.text+0x12d1): undefined reference to `sched_sizeof_ksegrp' | kern_thread.o(.text+0x131b): undefined reference to `sched_sizeof_kse' | subr_trap.o: In function `userret': | subr_trap.o(.text+0x1b): undefined reference to `sched_userret' | subr_trap.o: In function `ast': | subr_trap.o(.text+0x5ef): undefined reference to `sched_prio' | ksched.o: In function `ksched_attach': | ksched.o(.text+0x2e): undefined reference to `sched_rr_interval' | ksched.o: In function `ksched_setscheduler': | ksched.o(.text+0x2d6): undefined reference to `sched_prio' | ksched.o(.text+0x3c6): undefined reference to `sched_prio' | vm_zeroidle.o: In function `vm_pagezero': | vm_zeroidle.o(.text+0x40d): undefined reference to `sched_runnable' | vm_pageout.o: In function `vm_pageout_scan': | vm_pageout.o(.text+0x199c): undefined reference to `sched_nice' | machdep.o: In function `cpu_idle': | machdep.o(.text+0x166e): undefined reference to `sched_runnable' | *** Error code 1 | | Stop in /usr/obj/usr/src/sys/JUNO. | *** Error code 1 | | Stop in /usr/src
5.0-R: no network connectivity with generic kernel andfirewall_enable="YES"
Hi, I couldn't connect to anything on the network with my 5.0-RELEASE, with the generic kernel and rc.conf containing firewall_enable="YES" natd_interface="fxp0" natd_interface="fxp0" natd_flags="-t 255.255.255.255" The firewall loaded ok but natd silently vanished. When I tried to start natd manually it complained about divert being an unknown protocol. It seems ipfw can be loaded as a module but divert needs to be compiled into the kernel. Should this be documented, e.g. by a prominent comment in defaults/rc.conf, right by the side of firewall_enable? -- Regards, Georg. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: last KSE changes
On 2003-01-31 15:13:29 (+0100), Philip Paeps <[EMAIL PROTECTED]> wrote: > On 2003-01-28 11:24:41 (-0800), Julian Elischer <[EMAIL PROTECTED]> wrote: > > The rumour mill has been running wild on this but **AS FAR AS I KNOW** the > > breakages have been fixed, since no-one has told me directl of any current > > breakages. If you have any breakage from this commit, PLEASE TELL ME! [...] > Haven't been able to build a kernel for about two/three days, and your > commit looks like the one that might be the culprit... :-) ...and it wasn't :-) Sorry about that. > There's nothing particularly exciting in my config files, I don't think, but > I've attached them anyway, just in case. Sergey pointed out that I was missing a scheduler in my configs. Quick read through UPDATING shed light on the matter and the kernels build nicely again! False alarm, sorry :-o - Philip -- Philip Paeps Please don't CC me, I am [EMAIL PROTECTED] subscribed to the list. As soon as the flight attendant serves the coffee, the airliner encounters turbulence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removed?
Kris Kennaway <[EMAIL PROTECTED]> writes: > A number of ports have started to complain about a missing stropts.h > header..was this recently removed, and if so then what is the fix? I don't think we've ever supported STREAMS. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
psm not working on Toshiba 1905-s301 and 5.0 Release
I searched the archives, found a few similair problems, and possible resolutions, but none have worked for me. In windows, it is shown as an Alps Glidepoint on irq12, however fbsd refuses to find it. The device.hints file shows the correct info. I ran acpidump, but was not quite sure what to look for. (In one of the posts involving a sony with similair problems, someone said to check for MOUE to get the ID to modify psm.c, but neither exist in acpidump results) Any ideas? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ftpd mkdir problems
Using the default ftpd that comes with FreeBSD, in the mkdir command, why doesn't it expand '~', the cd and rmdir commands seem to. Passing over the code it just calls the c function with should expand it. ftp> cd ~will 250 CWD command successful. ftp> mkdir ~will/test 550 ~will/test: No such file or directory. ftp> mkdir test 257 "test" directory created. ftp> rmdir ~will/test 250 RMD command successful. ftp> -- David Rhodus To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Friday 31 January 2003 00:58, David Schultz wrote: > Thus spake Christopher Vance <[EMAIL PROTECTED]>: > > On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote: > > : On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote: > > : > Thus spake Steve Kargl <[EMAIL PROTECTED]>: > > : > > On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote: > > : > > > OT: Is there a good way to get the CVS metadata in /usr/src and > > : > > > /usr/ports without transferring the entire source tree over the > > : > > > network? On some machines, I'd like to be able to do a CVS > > : > > > {diff,log,update} now and then, but I don't have the disk space > > : > > > for the entire repository. I usually end up blowing away > > : > > > /usr/src and fetching a new copy from a CVS server, but I'm sure > > : > > > this is far from ideal for the people who pay for that server's > > : > > > bandwidth. > > : > > > > : > > anoncvs > > : > > > > : > > See the handbook for info. > > : > > > : > That's a great answer...to a different question. ;-) > > : > > : It's the correct answer. I assumed that you knew > > : how to use cvs. > > > > [...Chris Vance explains why cvsup is all he needs...] > > > > Perhaps you can explain why cvsup is the wrong answer... > > I don't know about Steve, but cvsup is the wrong answer for me > because it's a mirroring tool and not a version control tool. > Among the things I would like to do are: > > - Update to a specific version of a specific file from the > repository. Anoncvs will let you do this. cvs -D $ANONCVSROOT co -r$REVISION -d $WHERE_I_WANT_IT $WHERE_IT_IS > - Generate a diff between two revisions in the repository, You can use CVSweb for this quite ably. That's not a great solution for generating patches, but it's decent enough for trolling around the repo. > or between a version in the repository and some local > patches of my own. For that, you'd most easily check out the directory in which the files in question live, copy your local version into it, and use cvs diff. The repo information is cached in the CVS/ subdir, so it all works nicely: cvs diff -u myfile.c > - View logs for particular files. CVSweb is your friend. http://cvsweb.freebsd.org > [...old machine, limited disk space, mirroring the entire repo > infeasible...] > > Transferring the entire source tree over the network via anoncvs is > suboptimal when all I really want is a few kilobytes of 'CVS' > subdirectories. But I guess it will have to do for now. It's unnecessary. Use the -d option to cvs co to check out the subdirectories into a convenient place. > [1] When the system is an aging dual PPro or 200MHz Alpha using > SCSI, buying new drives is not practical. If you can afford it, retire the box to mail/firewall duty. A bare-bones 2.4GHz P4 system can be had for $500US if you shop hard. -- Chris BeHanna http://www.pennasoft.com Principal Consultant PennaSoft Corporation [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Smart Array 5312 (Compaq)
Thanks, Paul! I talked to our storage experts and as long as the driver already has 5i support, then all that's needed is to add the new id (which your patch does). Thanks, John John Cagle [EMAIL PROTECTED] Principal Member Technical Staff Industry Standard Servers Hewlett-Packard Company > -Original Message- > From: Paul Saab [mailto:[EMAIL PROTECTED]] > Sent: Thursday, January 30, 2003 7:46 PM > To: John > Cc: [EMAIL PROTECTED] > Subject: Re: Smart Array 5312 (Compaq) > > > Try this patch > > http://people.freebsd.org/~ps/ciss.diff > > John ([EMAIL PROTECTED]) wrote: > > Is anyone working on a driver for said raid controller? > > Here is a pciconf -lv (from 5.0-R) and a link for some info on the > > card. > > > > > > ne3@pci6:2:0: class=0x010400 card=0x40830e11 > chip=0xb1780e11 rev=0x01 hdr=0x00 > > class= mass storage > > subclass = RAID > > > > > http://h18004.www1.hp.com/products/servers/pro> liantstorage/arraycontro > > llers/smartarray5312/questionsanswers.html > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > -- > Paul Saab > Technical Yahoo > [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] > Do You .. uhh .. Yahoo!? > > 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: Fun and excitement with CURRENT
> From: stark <[EMAIL PROTECTED]> > Date: 30 Jan 2003 22:43:33 -0500 > Sender: [EMAIL PROTECTED] > > OK, I've got just 1.5 bugs left, then I'll be all CURRENT-ed :) > > (I'm using a brand new laptop. Much different than getting > BSD working on my desktops and servers :) > > Things that work : > - Making the third mouse button work on an IBM T30 (trackpoint & > touchpad model) you have to disable the touchpad in the BIOS. > > - Making CURRENT compile on 4.7 involves NOT using cvsupit to > do your cvsup-ing. or using it and editing it to use src-all > so you actually get the whole thing. > > - When compiling a kernel, don't be a smartass and assume you can > make your 4.7 KERNCONF file work in 5.0. start over with a 5.0 > GENERIC and modify it. You'll feel MUCH less stupid later. > > - X on a Radeon mobility 7500 is PERFECT. VERY VERY HAPPY! :) I assume IBM is still using the Mobility M7? IF so, I would not say "perfect". Are you using XFree86-Server-4.2.1? If so, the Radeon Mobility has two well known problems. Less serious is that line acceleration is broken and some things that re-draw lines fast will leave black lines on the display. You can eliminate these artifacts if you run the CVS drivers and add the option "NoLineAccel" to you configuration. This will be in 4.3.0 when it is release in about 2 weeks. If the display is turned off by BIOS (e.g. suspend, Fn-F3, or time-out), the display will restart very badly scrambled. No known fix for this that I have seen, although there is a work-around of switching to a text virtual terminal before the display turns off or by switching to a test virtual terminal after the display comes on and then cycling the display off and on. > - don't use apm and acpi at the same time. That is sound advice on any system. In fact, it looks like APM should check on the presence of ACPI when probing and bail out (with a suitable error) if it finds ACPI. Is there any case on any platform when both would make any sense at all? > UNFORTUNATELY, that last one has a solution : > > - DON'T USE ACPI. It really causes a problem. > If I turn acpi on (in kernel or as a module > same result) it will die a horrible, horrible > death. I'll get more info (as in, the text > it says when it crashes or the text it says > when it boots or whatever) after a couple of > reboots, but i was so happy it worked without > acpi i'm typing this now. debug later :) Try the acpi-jp list. There are many ACPI issues with IBMs (and many others) that are currently being discovered. I'm told that the latest BIOS makes ACPI work better, but still not correctly. > - Sound is really really weird. pcm doesn't work > with the i810 onboard (it works, but sound is > all static-y to the point of inaudibility, > and the OSS drivers seem to have a problem. > I think the oss drivers don't seem to work > without ACPI. or at least not so far. It > worked once, just not since :) Odd. I have not seen this to this point, but I am not running V5 on my T30 at the moment and I may not have ever tried it. The sound is fine with Stable. > so there ya go, 1.5 bugs. The ACPI took me quite > a while to work around because every time it booted > with it it crashed the system before I could do > anything productive. REALLY ANNOYING :) > (Is there a way to tell the kernel not to AUTOLOAD > ACPI on boot? That would be SUPER :) Yes. Stop the system at the "countdown" and enter "unset acpi_load" for a one-time fix and then add the line 'hint.acpi.0.disabled="1"' to /boot/device.hints. > Anyways, I'll keep the machine going and hopefully > come up with some ACPI patches in the next few days > that cause my laptop not to die a horrible death :) > (If you have any such patches let me know! :) ACPI patches would be greatly appreciated. If you find something, please be sure that you send it to [EMAIL PROTECTED] (While the "-jp" indicates a Japanese language list, I have never seen a message that lacked an English translation and the majority of the messages are all English.) 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: psm not working on Toshiba 1905-s301 and 5.0 Release
On Fri, 2003/01/31 at 10:00:28 -0500, Jason wrote: > I searched the archives, found a few similair problems, and possible > resolutions, but none have worked for me. > > In windows, it is shown as an Alps Glidepoint on irq12, however fbsd > refuses to find it. > > The device.hints file shows the correct info. I ran acpidump, but was not > quite sure what to look for. (In one of the posts involving a sony with > similair problems, someone said to check for MOUE meant MOUSE> to get the ID to modify psm.c, but neither exist in acpidump > results) > > Any ideas? I have a Satellite 1110, ignoring port errors gets the glidepoint detection to work. To do this, add hint.psm.0.flags="0x1000" (or-ed with any other flags you might want) to your device.hints. On my notebook, that is not the only quirk this glidepoint has: it completely stops sending interrupts as soon as you stop to move the cursor for a bit. I have found no other solution to this problem but to poll the glidepoint - this as the obvious disadvantage of using up some CPU time (< 0.5%), making the mouse movement feel a bit jittery and occasionally missing some very fast klicks. Since I do not use the glidepoint overly much, I can live with that. If your notebook has that problem too, I can supply a patch. - Thomas -- Thomas Moestl <[EMAIL PROTECTED]> http://www.tu-bs.de/~y0015675/ <[EMAIL PROTECTED]> http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: psm not working on Toshiba 1905-s301 and 5.0 Release
On Fri, 31 Jan 2003 at 10:00 -0500, Jason wrote: > I searched the archives, found a few similair problems, and possible > resolutions, but none have worked for me. Perhaps you have already seen my Toshiba Satellite 1005-S157 page which discusses a similar problem. See: http://www.4gh.net/hints/toshiba/satellite1005-s157.html In November you where trying 5.0 DP2 on a Toshiba 1901-S301. Is this the same machine? Did the suggestions to disable EISA and/or SCSI help in booting or has 5.0-RELEASE addressed the initial booting problem? > In windows, it is shown as an Alps Glidepoint on irq12, however fbsd > refuses to find it. > > The device.hints file shows the correct info. I ran acpidump, but was not > quite sure what to look for. (In one of the posts involving a sony with > similair problems, someone said to check for MOUE meant MOUSE> to get the ID to modify psm.c, but neither exist in acpidump > results) > > Any ideas? I have not yet tried FreeBSD 5.0 on my laptop, but src/isa/psm.c is pretty similar between 4.7 and -CURRENT and my patch appears to apply cleanly: % patch psm.c < ~/psm.c.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |diff -r -u ../src_dist/sys/isa/psm.c ./sys/isa/psm.c |--- ../src_dist/sys/isa/psm.c Wed Mar 27 11:53:35 2002 |+++ ./sys/isa/psm.cWed Oct 16 16:15:17 2002 -- Patching file psm.c using Plan A... Hunk #1 succeeded at 632 (offset -18 lines). Hunk #2 succeeded at 1034 (offset 34 lines). done % My patch is just a hack to make my Toshiba work correctly. I tend to think that test_aux_port() or its callers may need some work. I'm don't really like adding a third hack to the already existing two hacks which ignore other return codes. Someone more familiar with the mouse and keyboard driver code may want to look at moving the default processing for test_aux_port results to be the same as the current PSM_ACK case. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone diff -r -u ../src_dist/sys/isa/psm.c ./sys/isa/psm.c --- ../src_dist/sys/isa/psm.c Wed Mar 27 11:53:35 2002 +++ ./sys/isa/psm.c Wed Oct 16 16:15:17 2002 @@ -650,6 +650,7 @@ switch((i = test_aux_port(kbdc))) { case 1:/* ignore this error */ +case 2:/* ignore this error */ case PSM_ACK: if (verbose) log(LOG_DEBUG, "psm%d: strange result for test aux port (%d).\n", @@ -999,9 +1000,11 @@ * error code. Even if the controller HAS error with the aux port, * it will be detected later... * XXX: another incompatible controller returns PSM_ACK (0xfa)... + * XXX: Toshiba Satellite 1005-S157 returns 2... */ switch ((i = test_aux_port(sc->kbdc))) { case 1: /* ignore this error */ +case 2: /* ignore this error */ case PSM_ACK: if (verbose) printf("psm%d: strange result for test aux port (%d).\n",
Re: removed?
On Fri, Jan 31, 2003 at 09:21:51AM -0500, Mike Barcroft wrote: > Kris Kennaway <[EMAIL PROTECTED]> writes: > > A number of ports have started to complain about a missing stropts.h > > header..was this recently removed, and if so then what is the fix? > > I don't think we've ever supported STREAMS. Hmm..there must be something in the configure script that thinks we do. e.g. http://bento.freebsd.org/errorlogs/alpha-5-latest/nvi-1.81.5_2.log Can you investigate? Kris msg51355/pgp0.pgp Description: PGP signature
Re: last KSE changes
Your sources are way out of date.. specifically I think it looks like sys/proc.h is not being updated.. On Fri, 31 Jan 2003, Philip Paeps wrote: > On 2003-01-28 11:24:41 (-0800), Julian Elischer <[EMAIL PROTECTED]> wrote: > > The rumour mill has been running wild on this but **AS FAR AS I KNOW** the > > breakages have been fixed, since no-one has told me directl of any current > > breakages. If you have any breakage from this commit, PLEASE TELL ME! > > Is this the sort of breakage you were expecting: > > On an Alpha: > > | linking kernel > | init_main.o: In function `proc0_init': > | init_main.o(.text+0x428): undefined reference to `kse0_sched' > | init_main.o(.text+0x434): undefined reference to `ksegrp0_sched' > | init_main.o(.text+0x440): undefined reference to `proc0_sched' > | init_main.o(.text+0x44c): undefined reference to `thread0_sched' > | *** Error code 1 > | > | Stop in /usr/obj/usr/src/sys/PROSPERINA. > | *** Error code 1 > | > | Stop in /usr/src. > | *** Error code 1 > | > | Stop in /usr/src. > > On an i386: > > | linking kernel > | init_main.o: In function `proc0_init': > | init_main.o(.text+0x2b9): undefined reference to `kse0_sched' > | init_main.o(.text+0x2c3): undefined reference to `ksegrp0_sched' [...] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Hyperthreading and machdep.cpu_idle_hlt
So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non hyperthreading, I'll do when I can turn it off in BIOS next time I'm down there) however, I got a hint to turn machdep.cpu_idle_hlt on. Dmesg: (With Hyperthreading) CPU: Pentium 4 (1796.94-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff> real memory = 1073217536 (1023 MB) avail memory = 1034719232 (986 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 Programming 24 pins in IOAPIC #1 Programming 24 pins in IOAPIC #2 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee0 cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee0 cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec8 io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80400 I tested with machdep.cpu_idle_hlt=0 and machdep.cpu_idle_hlt=1 The results are here: http://bsdunix.net/performance all information on what command line options I used is in there. the difference with it on is pretty substantial, might be worth noting in tuning(7) -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Operator @ efnet.demon.co.ukAilleCat@EFNet Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Ruslan Ermilov <[EMAIL PROTECTED]>: > On Thu, Jan 30, 2003 at 09:58:15PM -0800, David Schultz wrote: > > I don't know about Steve, but cvsup is the wrong answer for me > > because it's a mirroring tool and not a version control tool. > > Among the things I would like to do are: > > > > - Update to a specific version of a specific file from the > > repository. > > > > - Generate a diff between two revisions in the repository, > > or between a version in the repository and some local > > patches of my own. > > > > - View logs for particular files. > > > > I asked the question in hopes that there would be some neat > > feature of cvsup that mocked up some CVS metadata for me, but > > since nobody has mentioned any such thing, I guess I'm out of > > luck. Mirroring the entire repository is not an option on > > machines with less than 6 GB of spare disk.[1] Transferring the > > entire source tree over the network via anoncvs is suboptimal when > > all I really want is a few kilobytes of 'CVS' subdirectories. > > But I guess it will have to do for now. > > > > > > [1] When the system is an aging dual PPro or 200MHz Alpha using > > SCSI, buying new drives is not practical. > > > Well then learn how to use anoncvs? I use anoncvs. My question was, given a source or ports tree without any CVS metadata, is there a way to obtain the tiny corresponding CVS/Entries and CVS/Repository files without checking out an entirely new copy of the tree via a busy, often overloaded, anoncvs server. Keep in mind that I'm not asking a ``can it be done?'' question. I've been doing it for years. Rather, I'm asking, ``can it be done more efficiently?'' So far, the best answer I've received is ``mirror the repository locally'' (thank you, David), which I already do on one machine to maintain a local branch and will consider doing on others. I have also considered writing a script to parse embedded $FreeBSD$ tags out of source files and mock up a CVS/Entries and CVS/Repository based on that information. Perhaps I will try that and see if it works passably well. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
:So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non :hyperthreading, I'll do when I can turn it off in BIOS next time I'm down :there) :... : :The results are here: : :http://bsdunix.net/performance : :all information on what command line options I used is in there. : :the difference with it on is pretty substantial, might be worth noting in :tuning(7) : :-Trish : :-- :Trish Lynch [EMAIL PROTECTED] Those results are indeed quite substantial. Before you modify tuning(7), though, lets wait a bit to see if anyone comes up with a fix to the performance issue when idle_hlt is turned off. In particular I would like to try using a per-cpu global test in the idle loop that avoids doing any locked bus cycles. Unfortunately I am not sure if I have any hyperthreading capable boxes. My primary machine is a pentium 4 but it is running -stable. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1296069572 Hz CPU: Pentium 4 (1296.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf07 Stepping = 7 Features=0x3febf9ff,ACC> It has HTT set but it's only a 1.2GHz box and I heard somewhere that only 2+ GHz P4's had hyperthreading. I noticed some MFCs to stable that suggested hyperthreading support but I do not know if full hyperthreading support has been MFCd yet or is intended to be MFCd to -stable. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
Matthew Dillon wrote: :So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non :hyperthreading, I'll do when I can turn it off in BIOS next time I'm down :there) :... : :The results are here: : :http://bsdunix.net/performance : :all information on what command line options I used is in there. : :the difference with it on is pretty substantial, might be worth noting in :tuning(7) : :-Trish : :-- :Trish Lynch [EMAIL PROTECTED] Those results are indeed quite substantial. Before you modify tuning(7), though, lets wait a bit to see if anyone comes up with a fix to the performance issue when idle_hlt is turned off. In particular I would like to try using a per-cpu global test in the idle loop that avoids doing any locked bus cycles. Unfortunately I am not sure if I have any hyperthreading capable boxes. My primary machine is a pentium 4 but it is running -stable. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1296069572 Hz CPU: Pentium 4 (1296.07-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf07 Stepping = 7 Features=0x3febf9ff AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,,ACC> It has HTT set but it's only a 1.2GHz box and I heard somewhere that only 2+ GHz P4's had hyperthreading. I noticed some MFCs to stable that suggested hyperthreading support but I do not know if full hyperthreading support has been MFCd yet or is intended to be MFCd to -stable. AFAIK, full hyperthreading support, as it is, has been merged to -stable. It consists of a patch to recognize the virtual CPUs, so they will be dealt with like any SMP system, as long as HTT is enabled on the BIOS. -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca TCO Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] In 1914, the first crossword puzzle was printed in a newspaper. The creator received $4000 down ... and $3000 across. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
Trish, Thanks for the tests, it would be good to also get results with hyperthreading turned off. However, I need you to pass the -o option to NPtcp and get an actual dat file, so that you can generate the graphs using the gnuplot config file I asked you to download. Having the results outputted in the text file is not very meaningful. From just eyeballing though, I can see that the maximum throughput is much higher in the second set of results. I'd still like the dat files and/or the gnuplot generated pngs, especially when hyperthreading is turned off, too. Thanks again, Trish. Regards, Bosko On Fri, Jan 31, 2003 at 01:04:52PM -0500, Trish Lynch wrote: > So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non > hyperthreading, I'll do when I can turn it off in BIOS next time I'm down > there) > > > > however, I got a hint to turn machdep.cpu_idle_hlt on. > > > Dmesg: (With Hyperthreading) > > CPU: Pentium 4 (1796.94-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 > > Features=0xbfebfbff GE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,> > real memory = 1073217536 (1023 MB) > avail memory = 1034719232 (986 MB) > > Programming 24 pins in IOAPIC #0 > IOAPIC #0 intpin 2 -> irq 0 > Programming 24 pins in IOAPIC #1 > Programming 24 pins in IOAPIC #2 > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > cpu0 (BSP): apic id: 0, version: 0x00050014, at 0xfee0 > cpu1 (AP): apic id: 6, version: 0x00050014, at 0xfee0 > cpu2 (AP): apic id: 1, version: 0x00050014, at 0xfee0 > cpu3 (AP): apic id: 7, version: 0x00050014, at 0xfee0 > io0 (APIC): apic id: 2, version: 0x00178020, at 0xfec0 > io1 (APIC): apic id: 3, version: 0x00178020, at 0xfec8 > io2 (APIC): apic id: 4, version: 0x00178020, at 0xfec80400 > > > I tested with machdep.cpu_idle_hlt=0 and machdep.cpu_idle_hlt=1 > > The results are here: > > > http://bsdunix.net/performance > > all information on what command line options I used is in there. > > the difference with it on is pretty substantial, might be worth noting in > tuning(7) > > -Trish > > -- > Trish Lynch [EMAIL PROTECTED] > Ecartis Core Team [EMAIL PROTECTED] > EFNet IRC Operator @ efnet.demon.co.uk AilleCat@EFNet > Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16 > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, 31 Jan 2003, Bosko Milekic wrote: > > Trish, > > Thanks for the tests, it would be good to also get results with > hyperthreading turned off. However, I need you to pass the -o > option to NPtcp and get an actual dat file, so that you can generate > the graphs using the gnuplot config file I asked you to download. > Having the results outputted in the text file is not very > meaningful. > > From just eyeballing though, I can see that the maximum throughput > is much higher in the second set of results. I'd still like the dat > files and/or the gnuplot generated pngs, especially when > hyperthreading is turned off, too. > > Thanks again, Trish. > > Regards, > Bosko > I have the .dat's for you, unfortunately, the output is different, so you'll have to modify the .cfg for gnuplot :) -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Operator @ efnet.demon.co.ukAilleCat@EFNet Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, Jan 31, 2003 at 01:45:56PM -0500, Trish Lynch wrote: > I have the .dat's for you, unfortunately, the output is different, so > you'll have to modify the .cfg for gnuplot :) > > -Trish I have HTT for my CPU, is there any "hack" to the BIOS to enable HyperThreading? Jiawei Ye -- "Without the userland, the kernel is useless." --inspired by The Tao of Programming To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
> I have HTT for my CPU, is there any "hack" to the BIOS to enable > HyperThreading? > You might try updating your BIOS. Ken To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
:AFAIK, full hyperthreading support, as it is, has been merged to :-stable. It consists of a patch to recognize the virtual CPUs, so they :will be dealt with like any SMP system, as long as HTT is enabled on the :BIOS. : :-- :Daniel C. Sobral (8-DCS) :Gerencia de Operacoes Yah. Shoot, well this Sony VAIO desktop has a P4 with HTT set in it, but it doesn't have an APIC, the BIOS is clueless, and there is no mptable, so I guess I am S.O.L. in regards to using hyperthreading on this box. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, Jan 31, 2003 at 11:08:38AM -0800, Matthew Dillon wrote: > > :AFAIK, full hyperthreading support, as it is, has been merged to > :-stable. It consists of a patch to recognize the virtual CPUs, so they > :will be dealt with like any SMP system, as long as HTT is enabled on the > :BIOS. > : > :-- > :Daniel C. Sobral (8-DCS) > :Gerencia de Operacoes > > Yah. Shoot, well this Sony VAIO desktop has a P4 with HTT set in > it, but it doesn't have an APIC, the BIOS is clueless, and there > is no mptable, so I guess I am S.O.L. in regards to using hyperthreading > on this box. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> Why do you think that hlt-ing the CPU(s) when idle would actually improve performance in this case? My only suspicion is that perhaps this reduces scheduling on the auxiliary 'logical' (fake) CPUs, thereby indirectly reducing cache ping-ponging and abuse. I would imagine that both units sharing the same execution engine in the HTT-enabled model would be effectively 'hlt'-ed when one of the two threads executes an 'hlt' until the next timer tick. I guess we'll wait for the two other data sets from Trish: one with HTT off, and cpu_idle_hlt=0, and the other with HTT off, and cpu_idle_hlt=1, before figuring this out. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS over TCP doesn't umount
Tinkering with NFS over TCP through a firewall, I ran across the following: # mount_nfs -3TN server:/path /mnt Generates the following traffic: UDP exchanges with server port 111 (rpcbind) TCP exchanges with server ports 1023 and 2049 That is, if your firewall allows UDP 111 through, then NFS over TCP can mount and function through it. But, umount is a different story: # umount /mnt Bad MNT RPC: RPC: Timed out The following tcpdump trace shows that the umount is using UDP transport, even though the filesystem was mounted using TCP transport: 11:21:42.811506 client.1124 > server.2049: F 129:129(0) ack 125 win 1 7396 (DF) 11:21:42.811912 client.962 > server.111: udp 56 11:21:42.812446 server.2049 > client.1124: . ack 130 win 33176 (DF) 11:21:42.812596 server.2049 > client.1124: F 125:125(0) ack 130 win 3 3176 (DF) 11:21:42.812614 client.1124 > server.2049: . ack 126 win 17395 (DF) 11:21:42.813195 server.111 > client.962: udp 28 11:21:42.813336 client.961 > server.1023: udp 128 11:21:45.817521 client.961 > server.1023: udp 128 11:21:48.827565 client.961 > server.1023: udp 128 11:21:51.837612 client.961 > server.1023: udp 128 11:21:54.847657 client.961 > server.1023: udp 128 11:21:57.857700 client.961 > server.1023: udp 128 11:22:00.867747 client.961 > server.1023: udp 128 This is reproducible with both a 4.3-RELEASE client and a recent -CURRENT client. The server is running 4.3-RELEASE, if it's relevant. Tim Kientzle To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
Bosko Milekic wrote: > > > On Fri, Jan 31, 2003 at 11:08:38AM -0800, Matthew Dillon wrote: > > > > :AFAIK, full hyperthreading support, as it is, has been merged to > > :-stable. It consists of a patch to recognize the virtual CPUs, so they > > :will be dealt with like any SMP system, as long as HTT is enabled on the > > :BIOS. > > : > > :-- > > :Daniel C. Sobral (8-DCS) > > :Gerencia de Operacoes > > > > Yah. Shoot, well this Sony VAIO desktop has a P4 with HTT set in > > it, but it doesn't have an APIC, the BIOS is clueless, and there > > is no mptable, so I guess I am S.O.L. in regards to using hyperthreadin g > > on this box. > > > > -Matt > > Matthew Dillon > > <[EMAIL PROTECTED]> > > Why do you think that hlt-ing the CPU(s) when idle would actually > improve performance in this case? My only suspicion is that perhaps > this reduces scheduling on the auxiliary 'logical' (fake) CPUs, > thereby indirectly reducing cache ping-ponging and abuse. I would > imagine that both units sharing the same execution engine in the > HTT-enabled model would be effectively 'hlt'-ed when one of the two > threads executes an 'hlt' until the next timer tick. The cache and most of the execution hardware is shared. The execution units can run something like 4 instructions per clock. If the "idle" logical core is in a spinloop, then it is generating instructions for execution, so you are dividing the execution resources between one context that is doing real work, and the other context that is burning off the "excess" resources. Overall, it is a huge loss. It is absolutely essential that logical cpus be halted when they are not doing useful work. Why bother with HTT on a single physical cpu system? The problem with the x86 instruction set is that it is Really Hard(TM) to extract enough parallel work from the instruction stream to keep all the pipelines running at full speed all the time. I remember when the P4 first came out, there was a lot of ridicule since the decoder simply didn't have enough bandwidth to generate enough micro-ops to keep the pipelines busy in already ideal situations. Intel grand plan is to add lots more pipelines, more logical cpus etc. The P4 division figures this will scale much more effectively than trying to make the compilers better and dedicating much more resources trying to squeeze more parallelism out of a single x86 instruction stream. Under ideal circumstances, HTT would be a win. ie: there would be lots of processes with 5-10 threads so that we could dispatch a process to a physical cpu and try and arrange for its threads to run on the logical cores (think 4 or 8 or even 16 logical contexts down the road). That way you get a single page table tree to cache in the TLB rather than trying to split the TLB 2 (or 4 or 8 or ...) ways. The threads would be better likely to have locality of reference so make better use of the physical L2 cache etc. This happens to work well in theory on the highly threaded windows world... Note "in theory". Windows needs HTT-aware tuning and algorithms to make this work better, right now it seems to be not that smart about scheduling etc. Although, that is a lot better than the situation that we're in right now. :-( Personally, I doubt that HTT will buy much on FreeBSD, apart from being buzzword compliant. I'd actually like a compile option or boot tunable so that it to be turned on or off (and treated like a regular Xeon SMP system). Single-physical-cpu systems already have this compile option, it is called 'options SMP' :-). But if you have 2x P4 Xeons, it would be nice to be able to use them as a normal 2 way system rather than 4 logical ways. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
: Why do you think that hlt-ing the CPU(s) when idle would actually : improve performance in this case? My only suspicion is that perhaps : this reduces scheduling on the auxiliary 'logical' (fake) CPUs, : thereby indirectly reducing cache ping-ponging and abuse. I would : imagine that both units sharing the same execution engine in the : HTT-enabled model would be effectively 'hlt'-ed when one of the two : threads executes an 'hlt' until the next timer tick. : : I guess we'll wait for the two other data sets from Trish: one with : HTT off, and cpu_idle_hlt=0, and the other with HTT off, and : cpu_idle_hlt=1, before figuring this out. : :-- :Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] I am almost certain that it is related to pipeline stalls created by the fairly long (in instructions) idle loop and the locked bus cycles used by the mutex code. It could also possibly be related to L1 cache contention. I think that if we can fit the idle loop for the 'logical' processor into a single instruction cache line and a single data cache line, accessing a single memory location without any locked bus cycles, that it would solve the problem. Unfortunately I have no boxes I can do testing on so this is just a guess. Another solution would be to have a global mask of 'idle' cpus and send an IPI to them when a new KSE is scheduled on a non-idle cpu that would simply serve to wakeup the HLT. IPIs are nasty, but there are large (power consumption) advantages to standardizing on the HLT methodology. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
:The cache and most of the execution hardware is shared. The execution :units can run something like 4 instructions per clock. If the "idle" :logical core is in a spinloop, then it is generating instructions for :execution, so you are dividing the execution resources between one context :that is doing real work, and the other context that is burning off the :"excess" resources. Overall, it is a huge loss. It is absolutely essential :that logical cpus be halted when they are not doing useful work. Ah, that makes sense. Are the two logical cpus shared 50-50? -Matt :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, 31 Jan 2003, Peter Wemm wrote: > > Personally, I doubt that HTT will buy much on FreeBSD, apart from being > buzzword compliant. I'd actually like a compile option or boot tunable so > that it to be turned on or off (and treated like a regular Xeon SMP > system). Single-physical-cpu systems already have this compile option, it > is called 'options SMP' :-). But if you have 2x P4 Xeons, it would be nice to > be able to use them as a normal 2 way system rather than 4 logical ways. > boot tunable would rock, then I wouldn;t have to had had BIOS access to a machine thats 2 hours away by car to turn HTT off (it just happened that it was enabled by default when they installed the machine) (which of course made it nice to try this on, but getting the second set of data with HTT turned off is going to be a pain) What I need is someone with an HTT capable SMP box that can turn it on and off to run these benchmarks with HTT on and off... then we'd have a good idea of the performance hit. -Trish -- Trish Lynch[EMAIL PROTECTED] Ecartis Core Team [EMAIL PROTECTED] EFNet IRC Operator @ efnet.demon.co.ukAilleCat@EFNet Key fingerprint = 781D 2B47 AA4B FC88 B919 0CD6 26B2 1D62 6FC1 FF16 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On 31-Jan-2003 Daniel C. Sobral wrote: > Matthew Dillon wrote: >> :So, at the request of bmilekic, I ran netpipe on a hyperthreading box (non >> :hyperthreading, I'll do when I can turn it off in BIOS next time I'm down >> :there) >> :... >> : >> :The results are here: >> : >> :http://bsdunix.net/performance >> : >> :all information on what command line options I used is in there. >> : >> :the difference with it on is pretty substantial, might be worth noting in >> :tuning(7) >> : >> :-Trish >> : >> :-- >> :Trish Lynch[EMAIL PROTECTED] >> >> Those results are indeed quite substantial. Before you modify >> tuning(7), though, lets wait a bit to see if anyone comes up with a >> fix to the performance issue when idle_hlt is turned off. In particular >> I would like to try using a per-cpu global test in the idle loop that >> avoids doing any locked bus cycles. >> >> Unfortunately I am not sure if I have any hyperthreading capable boxes. >> My primary machine is a pentium 4 but it is running -stable. >> >> Timecounter "i8254" frequency 1193182 Hz >> Timecounter "TSC" frequency 1296069572 Hz >> CPU: Pentium 4 (1296.07-MHz 686-class CPU) >> Origin = "GenuineIntel" Id = 0xf07 Stepping = 7 >> Features=0x3febf9ff> AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,,ACC> >> >> It has HTT set but it's only a 1.2GHz box and I heard somewhere that only >> 2+ GHz P4's had hyperthreading. I noticed some MFCs to stable that >> suggested hyperthreading support but I do not know if full hyperthreading >> support has been MFCd yet or is intended to be MFCd to -stable. > > AFAIK, full hyperthreading support, as it is, has been merged to > -stable. It consists of a patch to recognize the virtual CPUs, so they > will be dealt with like any SMP system, as long as HTT is enabled on the > BIOS. Well, sort of. We have no way of knowing if it is off in the BIOS unless we use the ACPI tables to enumerate CPU's (which we don't), so turning it off in the BIOS won't turn it off in FreeBSD for the time being. :) -- 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
Re: Hyperthreading and machdep.cpu_idle_hlt
On 31-Jan-2003 leafy wrote: > On Fri, Jan 31, 2003 at 01:45:56PM -0500, Trish Lynch wrote: >> I have the .dat's for you, unfortunately, the output is different, so >> you'll have to modify the .cfg for gnuplot :) >> >> -Trish > I have HTT for my CPU, is there any "hack" to the BIOS to enable HyperThreading? Having HTT does _not_ mean you actually have multiple cores in your physical CPU. You will see a separate line in your dmesg giving the number of cores per CPU if you do. The BIOS really has nothing to do with this, it all comes from registers returned from the CPUID instruction. -- 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
Re: Hyperthreading and machdep.cpu_idle_hlt
On 31-Jan-2003 Matthew Dillon wrote: > >:AFAIK, full hyperthreading support, as it is, has been merged to >:-stable. It consists of a patch to recognize the virtual CPUs, so they >:will be dealt with like any SMP system, as long as HTT is enabled on the >:BIOS. >: >:-- >:Daniel C. Sobral (8-DCS) >:Gerencia de Operacoes > > Yah. Shoot, well this Sony VAIO desktop has a P4 with HTT set in > it, but it doesn't have an APIC, the BIOS is clueless, and there > is no mptable, so I guess I am S.O.L. in regards to using hyperthreading > on this box. HTT set just means that you can check the value returned in %ebx from cpuid 1 to get the number of cores that your CPU contains. It most likely contains the value '1'. Only Xeons and very recent desktop P4's have multiple cores. -- 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
RE: Hyperthreading and machdep.cpu_idle_hlt
> From: Matthew Dillon [mailto:[EMAIL PROTECTED]] > > :The cache and most of the execution hardware is shared. The > execution > :units can run something like 4 instructions per clock. If the "idle" > :logical core is in a spinloop, then it is generating instructions for > :execution, so you are dividing the execution resources > between one context > :that is doing real work, and the other context that is > burning off the > :"excess" resources. Overall, it is a huge loss. It is > absolutely essential > :that logical cpus be halted when they are not doing useful work. > > Ah, that makes sense. Are the two logical cpus shared 50-50? Hyperthreading is also called symmetric multi-threading (hyperthread is a trademark of intel, SMT is the general term). The two logical cpu's are like a co-operative scheduler. Whenever there is a stall on one, the other wakes up on the same tick. THe most common cause for the stall is an access to memory. Ie when the first 'cpu' does a load-word, the memory controller tries to get that from L1->L2->L3->memory, with increasing latency. The other 'CPU' starts executing on the same cycle as the latency to the memory starts, and only stops when it too stalls. Thus the worst thing you could have would be a nop-loop with no stalls, which would squeeze the other to death. This is common in the network-processor world (e.g. AMCC, etc) since those applications are governed by memory latency. As the clock rate of memory has gone up, the overall latency to the first word has stayed relatively constant, so even though DDR 266 memory may have a much faster throughput, it takes just as long for that first access. Intel also has a speculative prefetch which tries to guess which memory will be needed next, and bring that in. There is an explicit prefetch in the SSE2/MMX set if you know better than the processor. This is good for for e.g. prefetch both halves of a tree before you do the compare. In practise I've found intel's numbers to be true, that the SMT gives you a ~20% boost, implying that there is nowhere close to a 50-50% split in normal use. --don To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
CD/RW Hangs with 5.0-RELEASE
Hello, This is the first time since adopting 5.0 that I've tried to do anything with my cd drive and I'm finding it impossible to work with. First, I installed ripit so that I could convert a couple CD's to mp3's. This fails with: dagrab: read raw ioctl failed at lba 0 length 12: Input/output error dagrab failed on Kittie - Pain at /usr/local/bin/ripit.pl line 369. Then, out of curiosity, I decided to see if I could even mount a regular data CD. I could. I could even unmount it. However, the CD drive would not spit out the disc until I rebooted the system. Some sort of lock on removing the CD from the drive stayed in place even after unmounting the drive. I know this drive works just fine as I just used it under Windows on the same box a couple days ago. I'm not sure what other info would be relevant, nor do I really know how to further diagnose this issue but I would be happy to supply any further information. I was unable to turn up anything by searching on Google or in the archives. Vitals: 5.0-RELEASE FreeBSD 5.0-RELEASE #0: Tue Jan 21 20:44:33 PST 2003 borges[117]% dmesg | grep acd0 acd0: CD-RW at ata1-master PIO4 acd0: READ_CD command timeout - resetting acd0: READ_CD command timeout - resetting acd0: READ_CD command timeout - resetting acd0: READ_CD command timeout - resetting Thanks in advance, Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, 31 Jan 2003, John Baldwin wrote: > >> AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,,ACC> > >> > >> It has HTT set but it's only a 1.2GHz box and I heard somewhere that only > >> 2+ GHz P4's had hyperthreading. I noticed some MFCs to stable that > >> suggested hyperthreading support but I do not know if full hyperthreading > >> support has been MFCd yet or is intended to be MFCd to -stable. > > > > AFAIK, full hyperthreading support, as it is, has been merged to > > -stable. It consists of a patch to recognize the virtual CPUs, so they > > will be dealt with like any SMP system, as long as HTT is enabled on the > > BIOS. > > Well, sort of. We have no way of knowing if it is off in the BIOS unless > we use the ACPI tables to enumerate CPU's (which we don't), so turning it > off in the BIOS won't turn it off in FreeBSD for the time being. :) > I have a 2,8GHz p4 here which has HTT and has a bios option for Interrupt mode: [APIC/PIC] I'm using APIC mode but an SMP (today's 4.x) kernel panics imediatly saying it can;t find an APIC. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, 31 Jan 2003, John Baldwin wrote: > > On 31-Jan-2003 leafy wrote: > > On Fri, Jan 31, 2003 at 01:45:56PM -0500, Trish Lynch wrote: > >> I have the .dat's for you, unfortunately, the output is different, so > >> you'll have to modify the .cfg for gnuplot :) > >> > >> -Trish > > I have HTT for my CPU, is there any "hack" to the BIOS to enable HyperThreading? > > Having HTT does _not_ mean you actually have multiple cores in your physical CPU. > You will see a separate line in your dmesg giving the number of cores per CPU > if you do. The BIOS really has nothing to do with this, it all comes from > registers returned from the CPUID instruction. do you need an SMP kernel to see this? > > -- > > 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 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On 31-Jan-2003 Julian Elischer wrote: > > > On Fri, 31 Jan 2003, John Baldwin wrote: > >> >> AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,,ACC> >> >> >> >> It has HTT set but it's only a 1.2GHz box and I heard somewhere that only >> >> 2+ GHz P4's had hyperthreading. I noticed some MFCs to stable that >> >> suggested hyperthreading support but I do not know if full hyperthreading >> >> support has been MFCd yet or is intended to be MFCd to -stable. >> > >> > AFAIK, full hyperthreading support, as it is, has been merged to >> > -stable. It consists of a patch to recognize the virtual CPUs, so they >> > will be dealt with like any SMP system, as long as HTT is enabled on the >> > BIOS. >> >> Well, sort of. We have no way of knowing if it is off in the BIOS unless >> we use the ACPI tables to enumerate CPU's (which we don't), so turning it >> off in the BIOS won't turn it off in FreeBSD for the time being. :) >> > I have a 2,8GHz p4 here which has HTT and has a bios option for > > Interrupt mode: [APIC/PIC] > > I'm using APIC mode but an SMP (today's 4.x) kernel > panics imediatly saying it can;t find an APIC. You need to have an mptable for it to work. The mptable will only list one processor, but it still needs to be there. -- 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
Re: Hyperthreading and machdep.cpu_idle_hlt
On 31-Jan-2003 Julian Elischer wrote: > > > On Fri, 31 Jan 2003, John Baldwin wrote: > >> >> On 31-Jan-2003 leafy wrote: >> > On Fri, Jan 31, 2003 at 01:45:56PM -0500, Trish Lynch wrote: >> >> I have the .dat's for you, unfortunately, the output is different, so >> >> you'll have to modify the .cfg for gnuplot :) >> >> >> >> -Trish >> > I have HTT for my CPU, is there any "hack" to the BIOS to enable HyperThreading? >> >> Having HTT does _not_ mean you actually have multiple cores in your physical CPU. >> You will see a separate line in your dmesg giving the number of cores per CPU >> if you do. The BIOS really has nothing to do with this, it all comes from >> registers returned from the CPUID instruction. > > > > do you need an SMP kernel to see this? No. -- 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
Re: NFS over TCP doesn't umount
Hi, > # umount /mnt > Bad MNT RPC: RPC: Timed out This behaviour is the same since we support NFS over TCP. The problem is, that the state of the nfs_mount isn't stored. That means that umount cannot look at the mountflags and decide what protocol it likes to use. Of course we can change this, but have to kill one existing mountflag because they are all used currently. I propose to remove "MNT_EXKERB", since all the kerberos nfs stuff has been removed. Have a look at mount.h yourself. If this is generally ok'd, I'll make a patch and commit it. Martin Martin Blapp, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On Fri, 31 Jan 2003, John Baldwin wrote: > > On 31-Jan-2003 Julian Elischer wrote: > > > > > > On Fri, 31 Jan 2003, John Baldwin wrote: > > > >> >> AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,,ACC> > >> >> > >> >> It has HTT set but it's only a 1.2GHz box and I heard somewhere that only > >> >> 2+ GHz P4's had hyperthreading. I noticed some MFCs to stable that > >> >> suggested hyperthreading support but I do not know if full hyperthreading > >> >> support has been MFCd yet or is intended to be MFCd to -stable. > >> > > >> > AFAIK, full hyperthreading support, as it is, has been merged to > >> > -stable. It consists of a patch to recognize the virtual CPUs, so they > >> > will be dealt with like any SMP system, as long as HTT is enabled on the > >> > BIOS. > >> > >> Well, sort of. We have no way of knowing if it is off in the BIOS unless > >> we use the ACPI tables to enumerate CPU's (which we don't), so turning it > >> off in the BIOS won't turn it off in FreeBSD for the time being. :) > >> > > I have a 2,8GHz p4 here which has HTT and has a bios option for > > > > Interrupt mode: [APIC/PIC] > > > > I'm using APIC mode but an SMP (today's 4.x) kernel > > panics imediatly saying it can;t find an APIC. > > You need to have an mptable for it to work. The mptable will > only list one processor, but it still needs to be there. if that comes from the BIOS, can it be simulated for uniprocessor machines with HTT? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: removed?
< said: > Hmm..there must be something in the configure script that thinks we do. > http://bento.freebsd.org/errorlogs/alpha-5-latest/nvi-1.81.5_2.log It erroneously thinks that because we have the grantpt() function, we have SEWERS and SVID3 ptys. It needs to learn how to use the posix_openpt() function, or else revert back to the !HAVE_SYS5_PTY code (which is also broken: it doesn't search the full range of possible pty names). -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Turn $25 into $45,000 MONTHLY, all automatic! 2588CMRd2-598mGjG7972Raq-23
This is IT! Don't miss out in this amazing opportunity. Join now for $25 and earn up to $45,000 MONTHLY Yes, I said monthly AND IT IS ALL AUTOMATED. Get FREE information. Just click the link below. www.mlmontarget.com This is FREE information that will amaze you on how much MONEY YOU CAN EARN FOR ONLY $25 per month. Many join multiple times and it is ALL AUTOMATED. We do all the hard work. Click below now for FREE information. www.mlmontarget.com Start getting your MONEY today!!! 8454CbFV6-461bgof1523wBxl0-180ztPb3459XesT5-575PZdt8733Anqp8-647GKkY1078Nswl71 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cisco vpnclient
what is the protocol they are using? On Fri, 31 Jan 2003, Christoph Kukulies wrote: > > Cisco is offering a VPN client for Linux. I wonder if it would be possible > to run this under FreeBSD. An extra linux kernel module is being built. > Is this already the 'ruled out'? > > If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x > beside my FreeBSD gateway. Would it be possible to use NAT to > extend the VPN (I only have one dedicated fixed IP on the gateway). > > Excuse if this is not exactly on target of -current. > > -- > Chris Christoph P. U. Kukulies [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
Re: dump -L and privilege
Moreover, the fact that the number of snapshots allowed on a filesystem is limited to a handful (src/sys/ufs/ffs/README.snapshot says 20) makes it possible for normal users to disrupt dump -L and other important operations that require snapshots. Alternative 2 seems a lot more sensible. Just my 2 KRW (1 USD ~= 1250 KRW) :D, Eugene On Thu, Jan 30, 2003 at 05:15:01PM -0600, Jacques A. Vidrine wrote: > On Wed, Jan 29, 2003 at 06:17:31PM -0800, Kirk McKusick wrote: > > Alternative 1 `usermount' > > The first would be > > to change the default for vfs.usermount == 1 and then have dump -L > > create the snapshot in a directory owned by "operator" (or by > > whatever user runs the dumps). Then the snapshot could be created, > > used, and deleted by that user. > > Alternative 2 `/sbin/snapshot' > > The other alternative would be to > > create a setuid-to-root program that would take a snapshot and > > chown it to the user that does dumps. This setuid program could > > then be invoked by dump -L to create a snapshot for it. > > Despite a distaste for setuid executables, I think I'd prefer a simple > /sbin/snapshot setuid program. Primarily, enabling `vfs.usermount' > gives more privileges to more users than I'm comfortable with. > Secondarily, /sbin/snapshot may be useful on its own. > > 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cisco vpnclient
On Fri, Jan 31, 2003 at 11:53:24AM +0100, Christoph Kukulies wrote: > > Cisco is offering a VPN client for Linux. I wonder if it would be possible > to run this under FreeBSD. An extra linux kernel module is being built. > Is this already the 'ruled out'? That's just it. FreeBSD can run Linux userland applications really well... compatibility within the kernel is a cow of another color. To do /some/ of the things the standard Cisco VPN client does, it would need to be a kernel module. To do /a lot/ of what it does, including just a basic IPsec implementation, it could all run in userland. I doubt that they will break things up that way. But if enough people ask, Cisco will make a client for FreeBSD. Or they might be willing to open up their protocol so that third parties can build their own clients. > If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x > beside my FreeBSD gateway. Would it be possible to use NAT to > extend the VPN (I only have one dedicated fixed IP on the gateway). Cisco VPN clients do work behind NAT (provided the NAT gateway can deal with the traffic). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
On 31-Jan-2003 Julian Elischer wrote: > > > On Fri, 31 Jan 2003, John Baldwin wrote: > >> >> On 31-Jan-2003 Julian Elischer wrote: >> > >> > >> > On Fri, 31 Jan 2003, John Baldwin wrote: >> > >> >> >> AT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,,ACC> >> >> >> >> >> >> It has HTT set but it's only a 1.2GHz box and I heard somewhere that only >> >> >> 2+ GHz P4's had hyperthreading. I noticed some MFCs to stable that >> >> >> suggested hyperthreading support but I do not know if full hyperthreading >> >> >> support has been MFCd yet or is intended to be MFCd to -stable. >> >> > >> >> > AFAIK, full hyperthreading support, as it is, has been merged to >> >> > -stable. It consists of a patch to recognize the virtual CPUs, so they >> >> > will be dealt with like any SMP system, as long as HTT is enabled on the >> >> > BIOS. >> >> >> >> Well, sort of. We have no way of knowing if it is off in the BIOS unless >> >> we use the ACPI tables to enumerate CPU's (which we don't), so turning it >> >> off in the BIOS won't turn it off in FreeBSD for the time being. :) >> >> >> > I have a 2,8GHz p4 here which has HTT and has a bios option for >> > >> > Interrupt mode: [APIC/PIC] >> > >> > I'm using APIC mode but an SMP (today's 4.x) kernel >> > panics imediatly saying it can;t find an APIC. >> >> You need to have an mptable for it to work. The mptable will >> only list one processor, but it still needs to be there. > > if that comes from the BIOS, can it be simulated for > uniprocessor machines with HTT? No. It provides information on how to route PCI interrupts through the IO APIC. ACPI also has this information, but we don't handle the IO APIC case right in ACPI yet. That is on my todo list but is a much larger task and will not be a 4.x feature. -- 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
KDE 3.1 Packages now available for 5.0-RELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We (kde@) have had some reported problems with the -CURRENT packages we made for KDE 3.1, not working correctly on FreeBSD 5.0-RELEASE, possibly due to our build system having a slightly newer than -RELEASE build of 5.0 on it. Arjan van Leeuwen has kindly produced some packages for us which do work with 5.0-RELEASE, and you can find them at: http://people.fruitsalad.org/avleeuwen/ There are still a couple of packages to come, but they will be uploaded later. Regards, Andy (on behalf of Arjan and the whole KDE@FreeBSD team) - -- Andy Fawcett | [EMAIL PROTECTED] | [EMAIL PROTECTED] "In an open world without walls and fences, | [EMAIL PROTECTED] we wouldn't need Windows and Gates." -- anon | [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE+OveFmTJ5KYb5sqYRAlTgAKCRh/fohMLiU78q/lA9bQvI2ionQwCeO3aI JZjhArgxco4GJ6jhz0PBQrU= =XMbc -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Mylex support under 5.0-R
Hi, Is it just me or is the Mylex driver broken under FreeBSD 5.0-Release? I couldn't dig up anything related in archives. I'm aware of bootup issues using Mylex cards, but I already have it installed on IDE and trying to work with a drive connected to a mylex controller locks up the system. Thank you, Simon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cisco vpnclient
Julian Elischer wrote: what is the protocol they are using? IPSec + IKE + group "extensions". The "extensions" are the problem. On Fri, 31 Jan 2003, Christoph Kukulies wrote: Cisco is offering a VPN client for Linux. I wonder if it would be possible to run this under FreeBSD. An extra linux kernel module is being built. Is this already the 'ruled out'? If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x beside my FreeBSD gateway. Would it be possible to use NAT to extend the VPN (I only have one dedicated fixed IP on the gateway). Excuse if this is not exactly on target of -current. -- Chris Christoph P. U. Kukulies [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 -- Marcin Dalecki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> Rebuilding the temporary build tree -- >>> stage 1: bootstrap tools -- >>> stage 2: cleaning up the object tree -- >>> stage 2: rebuilding the object tree -- >>> stage 2: build tools -- >>> stage 3: cross tools -- >>> stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Jan 31 15:08:21 PST 2003 -- >>> Kernel build for GENERIC completed on Fri Jan 31 15:40:14 PST 2003 -- >>> Kernel build for LINT started on Fri Jan 31 15:40:15 PST 2003 -- ===> vinum "Makefile", line 4447: warning: duplicate script for target "geom_bsd.o" ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning "The lmc driver is broken and is not compiled with LINT" /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type cc1: warnings being treated as errors /h/des/src/sys/kern/vfs_syscalls.c: In function `chroot': /h/des/src/sys/kern/vfs_syscalls.c:535: warning: `vp' might be used uninitialized in this function *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Smart Array 5312 (Compaq)
Well looks like it does work after all! I must not have created my install floppies correctly (panic was couldn't find init btw) . I moved a few a drives onto a 5i just so i could get 5.0 installed and running and recompiled the kernel with said patch and i can see and write to the drives. i have not tried booting off them yet but i will email back once i have. Should i submit a PR for this? On Fri, Jan 31, 2003 at 08:58:07AM -0800, Paul Saab wrote: > The actual panic message would be a good thing to see. > > John ([EMAIL PROTECTED]) wrote: > > yea i tried that. > > it almost works in 4.7. I can see the the drives in dmesg, > > but it panics when it comes time to mount the mfs file system. > > I'll have more time to test tomorrow (5.x, 4.x and CISS_BOARD_SA5 (no B) etc etc). > > > > > > Thanks! > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
State of the Union Report (backout request department)
(This is just a view from the sidelines; I generally do ports hacking and not kernel hacking, and thus my views might not carry much weight, but here goes anyways). One of the more interesting features of the FreeBSD development model seems to me to be the ability for people to request controversial CVS commits to be backed out pending further technical discussion. IMHO this seems like a wise (albeit nonintuitive) plan to avoid meta-discussions about what should and should not have been committed by whom and reviewed by whom (and so on and so forth). But recently (especially since the 5.0 release) the backout request mechanism seems to have fallen on hard times. Without too much difficulty, I was able to find 5 separate backout requests in this year's archive of cvs-all alone which were not quickly honored. (I'm not counting an ignored request for which the underlying change was apparently security-related). I'm not sure, but there may have been others, possibly on freebsd-current. The point I'm trying to make by posting this is not to take sides with anyone, assign blame or credit, or anything like that. I personally came up in the old Usenet days, and thus have already gone down that same road so many times that I would hope I've earned a lifetime "Get-Out-Of-Flames-Free" card for that reason alone (never mind various mailing lists and other places controversy loves to incubate ) But if we've got that model, it seems to me we ought to honor it, even if (especially if?) we think the request is frivolous or ill-intentioned. After all, if the backout request itself wasn't controversial, it would probably imply the original change wasn't controversial, and thus who would care to ask to back it out in the first place? I'm just asking folks to think about this so that the whole FreeBSD project can move forward and ideas can rise and fall on their technical merits, because frankly that's where the strength of FreeBSD lies -- in its technical merits. Mark Linimon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cisco vpnclient
> Cisco is offering a VPN client for Linux. I wonder if it would be > possible to run this under FreeBSD. An extra linux kernel module is > being built. Is this already the 'ruled out'? > > If this won't work, I'm afraid I will have to set a dedicated redhat > 6.x/7.x beside my FreeBSD gateway. Would it be possible to use NAT > to extend the VPN (I only have one dedicated fixed IP on the > gateway). Might I suggest using pppd + ssh. In my prior experience, it worked worlds better than the Cisco VPN client and was likely provided a more secure authentication (ssh keys vs. IKE?). As an added bonus, it ssh + pppd doesn't hijack your interface so you can connect to the Internet directly and to your office without having to send your normal Internet traffic through the office. Yes there are security problems with this, but running ipf(w) on the split host works exceedingly well and is generally a tighter firewall than what's put up to protect the office. ;) -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Hyperthreading and machdep.cpu_idle_hlt
In the last episode (Jan 31), Don Bowman said: > Thus the worst thing you could have would be a nop-loop with > no stalls, which would squeeze the other to death. I don't think this is possible, from looking at Intel's white papers. > In practise I've found intel's numbers to be true, that the SMT gives > you a ~20% boost, implying that there is nowhere close to a 50-50% > split in normal use. According to "Hyper-Threading Technology Architecture and Microarchitecture" at http://developer.intel.com/technology/itj/2002/volume06issue01/art01_hyper/vol6iss1_art01.pdf , the internal schedulers make no distinction between the two logical CPUs, and "To avoid deadlock and ensure fairness, there is a limit on the number of active entries that a logical processor can have in each scheduler's queue." That sounds like given identical processes running on both logical CPUs, you will get a 50-50% balance. I think for HT to be any help, FreeBSD's scheduler needs to know which pairs of CPUs share resources, so it can schedule one process per pair first, and any remaining runnable processes get put on the remaining CPUs, possibly allocated so threads belonging to the same process run on the same pair. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cisco vpnclient
On Fri, 2003-01-31 at 20:28, Sean Chittenden wrote: > > Cisco is offering a VPN client for Linux. I wonder if it would be > > possible to run this under FreeBSD. An extra linux kernel module is > > being built. Is this already the 'ruled out'? > > > > If this won't work, I'm afraid I will have to set a dedicated redhat > > 6.x/7.x beside my FreeBSD gateway. Would it be possible to use NAT > > to extend the VPN (I only have one dedicated fixed IP on the > > gateway). > > Might I suggest using pppd + ssh. In my prior experience, it worked > worlds better than the Cisco VPN client and was likely provided a more > secure authentication (ssh keys vs. IKE?). As an added bonus, it ssh > + pppd doesn't hijack your interface so you can connect to the > Internet directly and to your office without having to send your > normal Internet traffic through the office. Yes there are security > problems with this, but running ipf(w) on the split host works > exceedingly well and is generally a tighter firewall than what's put > up to protect the office. ;) -sc This is actually what I use to connect into Cisco (well, I use ppp+ssh). The downside is that right now, my "VPN concentrator" is being moved from one building to another, and I have no FreeBSD connectivity. Also, other companies might only allow inbound access via a proprietary VPN client. For those that also offer SSH, you're right, my make-shift VPN is much more flexible that what the Cisco VPN client provides. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc signature.asc Description: This is a digitally signed message part
Re: Cisco vpnclient
Sean Chittenden wrote: Cisco is offering a VPN client for Linux. I wonder if it would be possible to run this under FreeBSD. An extra linux kernel module is being built. Is this already the 'ruled out'? If this won't work, I'm afraid I will have to set a dedicated redhat 6.x/7.x beside my FreeBSD gateway. Would it be possible to use NAT to extend the VPN (I only have one dedicated fixed IP on the gateway). Might I suggest using pppd + ssh. In my prior experience, it worked worlds better than the Cisco VPN client and was likely provided a more secure authentication (ssh keys vs. IKE?). As an added bonus, it ssh + pppd doesn't hijack your interface so you can connect to the Internet directly and to your office without having to send your normal Internet traffic through the office. Yes there are security problems with this, but running ipf(w) on the split host works exceedingly well and is generally a tighter firewall than what's put up to protect the office. ;) -sc The "connection hijack" by Cisco is indeed a very silly thing, since the disabling of the routing of interfaces different from the *one true and very secure* IPSec connection it is establishing can be easly, very easly circumvented be deliberately changing a string in the cisco linux kernel module. You have just to change the string "eth" to "eth0" or whatever in the source code there. Well indeed some linux ethernet devices do not obey the "ethXX" naming schema, namely they register themself as "usbXXX" devices, so the whole thing in without any good reason in first place anyway. -- Marcin Dalecki To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cisco vpnclient
On Fri, 2003-01-31 at 21:20, Marcin Dalecki wrote: > The "connection hijack" by Cisco is indeed a very silly thing, Unfortunately, it's there because some corporate network policies demand it. And some companies are loath to allow Linux/FreeBSD/etc. on their networks because it can be defeated. -- brandon s allbery [openafs/solaris/japh/freebsd] [EMAIL PROTECTED] system administrator [linux/heimdal/too many hats] [EMAIL PROTECTED] electrical and computer engineering KF8NH carnegie mellon university [better check the oblivious first -ke6sls] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: State of the Union Report (backout request department)
Mark Linimon <[EMAIL PROTECTED]> writes: > (This is just a view from the sidelines; I generally do ports hacking > and not kernel hacking, and thus my views might not carry much > weight, but here goes anyways). > > One of the more interesting features of the FreeBSD development > model seems to me to be the ability for people to request controversial > CVS commits to be backed out pending further technical discussion. > IMHO this seems like a wise (albeit nonintuitive) plan to avoid > meta-discussions about what should and should not have been > committed by whom and reviewed by whom (and so on and so forth). > > But recently (especially since the 5.0 release) the backout request > mechanism seems to have fallen on hard times. Without too much > difficulty, I was able to find 5 separate backout requests in this > year's archive of cvs-all alone which were not quickly honored. > (I'm not counting an ignored request for which the underlying > change was apparently security-related). I'm not sure, but there > may have been others, possibly on freebsd-current. The archives might not be telling the whole story. A lot of times these things get handled behind closed doors, whether private e-mail or developer-only lists. Thankfully though, most conflicts *do* get resolved. :) Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: State of the Union Report (backout request department)
* De: Mike Barcroft <[EMAIL PROTECTED]> [ Data: 2003-01-31 ] [ Subjecte: Re: State of the Union Report (backout request department) ] > The archives might not be telling the whole story. A lot of times > these things get handled behind closed doors, whether private e-mail > or developer-only lists. Thankfully though, most conflicts *do* get > resolved. :) Might be nice if we had an internal trouble ticket system for things like this, TODOs that are high priority, and pending MFCs. I got the impression NetBSD does something like this for branch pullups that are needed? Then there's a clearer qudit trail, and it's easier to find out if things have "not been honoured". And to keep other sorts of things from falling behind. Thanx, juli. -- Juli Mallett <[EMAIL PROTECTED]> AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: State of the Union Report (backout request department)
On Fri, 31 Jan 2003, Mike Barcroft wrote: > The archives might not be telling the whole story. A lot of times > these things get handled behind closed doors, whether private e-mail > or developer-only lists. Thankfully though, most conflicts *do* get > resolved. :) I have always LOVED watching the commits and backouts. I find it much more exciting to watch the actual development commit by commit, watch the brainiacs audit each other, and resolve to the best course. It seems much better than the way Linux traditionally did it (although they seem to have moved to bitkeeper) and much more like a professional development team. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: dump -L and privilege
From: Jun Kuriyama <[EMAIL PROTECTED]> To: Kirk McKusick <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: Re: dump -L and privilege In-Reply-To: <[EMAIL PROTECTED]> X-ASK-Info: Whitelist match Is this enough? -r-sr-x--- 1 root operator 5750 Jan 31 22:13 mksnap_ffs o Should use filesystem device name rather than mountpoint? o Should use the group of device rather than "operator"? -- Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc. <[EMAIL PROTECTED]> // FreeBSD Project The mount command needs the mountpoint, not the device name, so the device name would only be needed if we want to use the group of the device rather than operator. I argue that we should use operator rather than the group of the device because the purpose of this command is to allow the dump program, run by people in the operator group, to take snapshots. At any rate, I have cleaned up the program and provided a Makefile and manual page (see below). The only semantic change that I made to your program was to do the `chown' before doing the `chmod' so as not to open a brief hole that would allow members of the default (wheel) group to get read access to the snapshot. Kirk McKusick # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # mksnap_ffs/Makefile # mksnap_ffs/mksnap_ffs.8 # mksnap_ffs/mksnap_ffs.c # mkdir mksnap_ffs echo x - mksnap_ffs/Makefile sed 's/^X//' >mksnap_ffs/Makefile << 'END-of-mksnap_ffs/Makefile' X# $FreeBSD$ X XPROG= mksnap_ffs XMAN= mksnap_ffs.8 X X.if defined(NOSUID) XBINMODE=550 X.else XBINMODE=4550 XBINOWN=root X.endif XBINGRP=operator X X.include END-of-mksnap_ffs/Makefile echo x - mksnap_ffs/mksnap_ffs.8 sed 's/^X//' >mksnap_ffs/mksnap_ffs.8 << 'END-of-mksnap_ffs/mksnap_ffs.8' X.\" X.\" Copyright (c) 2003 Networks Associates Technology, Inc. X.\" All rights reserved. X.\" X.\" This software was developed for the FreeBSD Project by Marshall X.\" Kirk McKusick and Network Associates Laboratories, the Security X.\" Research Division of Network Associates, Inc. under DARPA/SPAWAR X.\" contract N66001-01-C-8035 ("CBOSS"), as part of the DARPA CHATS X.\" research program. X.\" X.\" Redistribution and use in source and binary forms, with or without X.\" modification, are permitted provided that the following conditions X.\" are met: X.\" 1. Redistributions of source code must retain the above copyright X.\"notice, this list of conditions and the following disclaimer. X.\" 2. Redistributions in binary form must reproduce the above copyright X.\"notice, this list of conditions and the following disclaimer in the X.\"documentation and/or other materials provided with the distribution. X.\" 3. The names of the authors may not be used to endorse or promote X.\"products derived from this software without specific prior written X.\"permission. X.\" X.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND X.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE X.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE X.\" ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE X.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL X.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS X.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) X.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT X.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY X.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF X.\" SUCH DAMAGE. X.\" X.\" $FreeBSD$ X.\" X.Dd January 19, 2003 X.Dt MKSNAP_FFS 8 X.Os X.Sh NAME X.Nm mksnap_ffs X.Nd take a filesystem snapshot X.Sh SYNOPSIS X.Nm X.Ar mountpoint X.Ar snapshot_name X.Sh DESCRIPTION XThe X.Nm Xcommand creates a snapshot named X.Ar snapshot_name Xon the filesystem mounted at X.Ar mountpoint . XThe X.Ar snapshot_name Xargument must be contained within the filesystem mounted at X.Ar mountpoint . X.Pp XThe group ownership of the file is set to X.Dq operator ; Xthe owner of the file remains X.Dq root . XThe mode of the snapshot is set to be readable by the owner Xor members of the X.Dq operator Xgroup. X.Sh SEE ALSO X.Xr chmod 2 , X.Xr chown 8 , X.Xr mount_ffs 8 X.Sh HISTORY XA X.Nm Xcommand first appeared in X.Fx 5.0 . END-of-mksnap_ffs/mksnap_ffs.8 echo x - mksnap_ffs/mksnap_ffs.c sed 's/^X//' >mksnap_ffs/mksnap_ffs.c << 'END-of-mksnap_ffs/mksnap_ffs.c' X/* X * Copyright (c) 2003 Networks Associates Technology, Inc. X * All rights reserved. X * X * This software was developed for the Free
Re: Smart Array 5312 (Compaq)
John ([EMAIL PROTECTED]) wrote: > Well looks like it does work after all! I must not have created my install > floppies correctly (panic was couldn't find init btw) . I moved a few a > drives onto a 5i just so i could get 5.0 installed and running and > recompiled the kernel with said patch and i can see and write to the drives. i > have not tried booting off them yet but i will email back once i have. > > Should i submit a PR for this? I'll commit this stuff soon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
On 2003-01-30 21:38, David Schultz <[EMAIL PROTECTED]> wrote: > Thus spake Mike Makonnen <[EMAIL PROTECTED]>: > > Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on > > the repository remotely, so you don't need to have the files checked out localy. > > That's a pretty good solution, and I use those occasionally. It > would be a perfect solution if there were an 'rupdate', so I don't > have to (cd /tmp; cvs co src/file/i/want.c) > && cp /tmp/src/file/i/want.c /where/i/want/it > && rm -rf /tmp/src > all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Giorgos Keramidas <[EMAIL PROTECTED]>: > On 2003-01-30 21:38, David Schultz <[EMAIL PROTECTED]> wrote: > > Thus spake Mike Makonnen <[EMAIL PROTECTED]>: > > > Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on > > > the repository remotely, so you don't need to have the files checked out localy. > > > > That's a pretty good solution, and I use those occasionally. It > > would be a perfect solution if there were an 'rupdate', so I don't > > have to (cd /tmp; cvs co src/file/i/want.c) > > && cp /tmp/src/file/i/want.c /where/i/want/it > > && rm -rf /tmp/src > > all the time. > > # cd /tmp > # cvs -d 'repo magic' export -rHEAD src/file/i/want.c > > Does `cvs export' do the trick for you? Actually, 'cvs export' does the opposite of what I want to do. But thank you for mentioning it, because it's a good way to explain what I'm trying to do, so people don't keep assuming that my problem is not knowing how to use CVS. 'cvs checkout': create a copy of the sources AND CVS's administrative directories 'cvs export': just create a copy of the sources What I want to do: just create the administrative directories I'm aware that making CVS magically discover what version I have is a bit much to ask for, so I'm willing to tell it what tag to use. Unfortunately, I don't think the facility I want exists, but I'm going to try to implement a workaround when I have a moment. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
* De: Giorgos Keramidas <[EMAIL PROTECTED]> [ Data: 2003-01-31 ] [ Subjecte: Re: Seat-belt for source upgrades from stable to current ] > On 2003-01-30 21:38, David Schultz <[EMAIL PROTECTED]> wrote: > > Thus spake Mike Makonnen <[EMAIL PROTECTED]>: > > > Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on > > > the repository remotely, so you don't need to have the files checked out localy. > > > > That's a pretty good solution, and I use those occasionally. It > > would be a perfect solution if there were an 'rupdate', so I don't > > have to (cd /tmp; cvs co src/file/i/want.c) > > && cp /tmp/src/file/i/want.c /where/i/want/it > > && rm -rf /tmp/src > > all the time. > > # cd /tmp > # cvs -d 'repo magic' export -rHEAD src/file/i/want.c > > Does `cvs export' do the trick for you? Further, export -d somedir might be useful in this situation to get the files where you want them, though sometimes -d does not DWIM, so I'm not sure :) -- Juli Mallett <[EMAIL PROTECTED]> AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: State of the Union Report (backout request department)
Thus spake Wesley Morgan <[EMAIL PROTECTED]>: > On Fri, 31 Jan 2003, Mike Barcroft wrote: > > > The archives might not be telling the whole story. A lot of times > > these things get handled behind closed doors, whether private e-mail > > or developer-only lists. Thankfully though, most conflicts *do* get > > resolved. :) > > I have always LOVED watching the commits and backouts. I find it much more > exciting to watch the actual development commit by commit, watch the > brainiacs audit each other, and resolve to the best course. It seems much > better than the way Linux traditionally did it (although they seem to have > moved to bitkeeper) and much more like a professional development team. The problem is that once something is in the tree and someone asks for a backout, there is a stigma attached to it. It's as though the original committer would be admitting that he's wrong by backing it out, even if his commit is justified. So he gets defensive about it (and sometimes everyone else gets annoyed while their builds fail), and thus a DSW breaks out and people spend hours of their time being generally nasty and unproductive. People need to think of backouts as a form of bookkeeping and not as an admission of error. They should also try to minimize their occurrence, i.e. I shouldn't be able to read through the CVS logs and predict ``uh oh, there's gonna be hell about this...'' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Juli Mallett <[EMAIL PROTECTED]>: > * De: Giorgos Keramidas <[EMAIL PROTECTED]> [ Data: 2003-01-31 ] > [ Subjecte: Re: Seat-belt for source upgrades from stable to current ] > > On 2003-01-30 21:38, David Schultz <[EMAIL PROTECTED]> wrote: > > > Thus spake Mike Makonnen <[EMAIL PROTECTED]>: > > > > Use the r version of the cvs commands (like cvs rlog and rdiff). They operate >on > > > > the repository remotely, so you don't need to have the files checked out >localy. > > > > > > That's a pretty good solution, and I use those occasionally. It > > > would be a perfect solution if there were an 'rupdate', so I don't > > > have to (cd /tmp; cvs co src/file/i/want.c) > > > && cp /tmp/src/file/i/want.c /where/i/want/it > > > && rm -rf /tmp/src > > > all the time. > > > > # cd /tmp > > # cvs -d 'repo magic' export -rHEAD src/file/i/want.c > > > > Does `cvs export' do the trick for you? > > Further, export -d somedir might be useful in this situation to get the > files where you want them, though sometimes -d does not DWIM, so I'm > not sure :) That works when the revision has a symbolic tag associated with it, but export seems to be picky and won't do numeric revision numbers of particular files. I guess I could always go by date. And yes, -d is picky, too; you can't export into your working directory. Still, not bad... It doesn't address the entire problem I mentioned before, because I still want to do diffs between local revisions and the repository. This thread is just a subthread of the original thread in which I guess we're talking about how to do a 'cvs update' without a copy of the repository. (Sorry Giorgos, your idea actually works for updates, just not for the original question I was asking. I was confused. ENOSLEEP.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: intalling from cds
On 31-Jan-2003 Kirk R Wythers wrote: > I ran into a strange issue while trying to do a cd install from the > 5.0-RELEASE cds. After booting from the cd, the install skips the kernel > configuration menue completely (I've never seen that before), then jumps > right into sysinsall. I select 'standard install', and I see the folloing: The USERCONFIG stuff isn't around anymore in 5.0. > afd0 > da0 > da1 > > adf0 is a zip250 drive on this box. Why is that showing up here? If I > choose to use the entire disk on da0 and da1 (no dual boot concerns), and > install the 'standard mbr' on the da0, I seem to be stuck going back to the > 'choose the drive' > > afd0 > da0 > da1 > > menue without getting to the the disklable editor > > What am I doing wrong? thanks Use Tab to move down to 'Ok' after you have finished using fdisk on your drives and then hit Enter to continue. -- 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
intalling from cds
I ran into a strange issue while trying to do a cd install from the 5.0-RELEASE cds. After booting from the cd, the install skips the kernel configuration menue completely (I've never seen that before), then jumps right into sysinsall. I select 'standard install', and I see the folloing: afd0 da0 da1 adf0 is a zip250 drive on this box. Why is that showing up here? If I choose to use the entire disk on da0 and da1 (no dual boot concerns), and install the 'standard mbr' on the da0, I seem to be stuck going back to the 'choose the drive' afd0 da0 da1 menue without getting to the the disklable editor What am I doing wrong? thanks ps... sorry for cross posting, but I wasn't sure which group this fell to the best... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: copy extended attributes
Forgive me for being dense, but can you expand on your concerns? Doug On Fri, 31 Jan 2003, Daniel C. Sobral wrote: > I'm starting to have a bad feeling about mergemaster and /etc's full of > acl and mac labels... > > Robert Watson wrote: > > > > I have local patches submitted by Chris Faulhaber to copy ACLs when a file > > is copied (or moved between file systems) that I've been meaning to finish > > testing and merge. Likewise, for gzip, bzip, and others when a file is > > replaced. This wouldn't address the general issue of copying extended > > attributes, but is a necessary step. Presumably if we did extend cp, et > > al, to copy EA's, they should explicitly copy only user namespace EAs, not > > system EAs. There's been some recent e-mail on the Linux side about > > interfaces to copy ACLs from one file to another, but I haven't had a > > chance to review those changes as yet to see whether we should pick them > > up. > > -- If it's moving, encrypt it. If it's not moving, encrypt it till it moves, then encrypt it some more. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message