Re: PATCHES for Kris Kennaway to commit
Terry Lambert wrote: > > Giorgos Keramidas wrote: > > > > Terry Lambert <[EMAIL PROTECTED]> wrote: > > > Steve Kargl wrote: > > > > > > > > man send-pr > > > > > > Yeah; I'd prefer it if "send-pr" ran under Windows, or of > > > FreeBSD would support WinModems. > > > > What fails to work for you in the Web Interface at > > http://www.FreeBSD.org/send-pr.html ? > > Attaching patches. It does not support the HTTP drop > target for upload, so a cut and paste will change tabs > into spaces, so the patch won't apply cleanly. I find that the --ignore-whitespace option to patch usually handles this nicely. -- "We will not tire, we will not falter, and we will not fail." - George W. Bush, President of the United States September 20, 2001 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uucp @ sourceforge
Terry Lambert wrote: > Maxim Sobolev wrote: > > I agree with Kris. These days it is not a big problem, especially for > > an opensource project, such as UUCP. Most obvious possibility is a > > Sourceforge - it provides all what is necessary (i.e. cvs repo, bug > > tracking database, mailing lists, www space, ftp space etc) at zero > > cost. And in my view it is even better option than /usr/src, because > > it is much easier to allow interested people to have r/w access to > > that private repo. > > Sourceforge is based on the premise that you can create an > Open Source project by declaring one, which is untrue. If > you want my opnions in detail, check the -chat and -advocacy > archives. I am not sure how this could defeat the fact that you can get a necessary ftp/www/cvs/etc space easily. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PATCHES for Kris Kennaway to commit
On 07-Oct-01 Terry Lambert wrote: > As to the work itself, I have been avoiding it, since we have > a new person at ClickArray whose "trial by fire" is building > an updated "developer workstation release CDROM" based on the > FreeBSD 4.3-RELEASE plus our heavily modified kernel code, > and our distribution package for our current release product > (i.e. a CDROM that can be used to install engineering desktop > machines, and can also be used as a "golden master" for the > release engineering process). > > As soon as he has successfully been mentored through this > process (which involves many local patches, some of which I > posted to you, and which must be manually integrated, since > the FreeBSD "add patches during ``make release''" doesn't > work if you are patching the top level release Makefile), I > will be able to turn my attention to it without stepping on > his toes or his learning process. Actually, while that is painful, it's not that hard to work around. You need your big honkin' patch file that you list in LOCAL_PATCHES and then you need to patch src/release/Makefile manually before you kick off the release. The only extra step is patching src/release/Makefile manually, and there isn't a good way to workaround that, since you always have to bootstrap from something. I've used this approach many times myself in testing release Makefile changes. It's not that hard. :-P -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "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: uucp @ sourceforge
Maxim Sobolev wrote: > > Sourceforge is based on the premise that you can create an > > Open Source project by declaring one, which is untrue. If > > you want my opnions in detail, check the -chat and -advocacy > > archives. > > I am not sure how this could defeat the fact that you can get a necessary > ftp/www/cvs/etc space easily. It doesn't defeat that. It only defeats the project living on after I am run over by a bus, since the project will be unable to attract outside participation if it is hosted at SourceForge. You can't cookie-cutter Open Source projects, at least not the way they are trying to do it. As I said before, you need to read my objections in the -current and -advocacy lists. Realize that I have participated in the genesis of no less than 5 open source projects, 4 of which are still going. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
For your amusement..
Just a FYI to people not on the ia64 list... All bow before Doug Rabson, the mighty! :-) peter@overcee[11:23am]~src/sys/ia64/compile/SMALL-203# telnet -K ia64 Trying 10.0.0.21... Connected to ia64.wemm.org. Escape character is '^]'. FreeBSD/ia64 (ia64.wemm.org) (ttyp0) login: peter Password: Last login: Thu Oct 4 12:26:02 from overcee Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT (SMALL) #1: Mon Oct 8 10:33:33 PDT 2001 Welcome to FreeBSD! $ uname -a FreeBSD ia64.wemm.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Mon Oct 8 10:33:33 PDT 2001 [EMAIL PROTECTED]:/home/src/sys/ia64/compile/SMALL ia64 $ df Filesystem 1K-blocks UsedAvail Capacity Mounted on /dev/da1a 254063 124581 10915753%/ devfs 110 100%/dev procfs 880 100%/proc $ ps -axl UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND 0 0 0 0 -16 0 05 sched DLs ??0:00.00 (swapper) 0 1 0 0 8 0 1312 23 wait ILs ??0:00.01 (init) 0 2 0 0 -16 0 05 psleep DL??0:00.00 (pagedaemon) 0 3 0 0 20 0 05 psleep DL??0:00.00 (vmdaemon) 0 4 0 0 20 0 05 pgzero DL??0:00.00 (pagezero) 0 5 0 0 -16 0 05 psleep DL??0:00.01 (bufdaemon) 0 6 0 0 20 0 05 syncer DL??0:00.03 (syncer) 010 0 48 -16 0 05 - RL??7:59.29 (idle) 011 0 0 -44 0 05 - WL??0:00.02 (swi1: net) 012 0 0 -48 0 05 - WL??0:01.11 (swi6: tty:sio clock) 013 0 0 -32 0 05 - WL??0:00.00 (swi4: vm) 014 0 0 76 0 05 sleep DL??0:00.04 (random) 015 0 0 -28 0 05 - WL??0:00.00 (swi5: task queue) 016 0 0 -40 0 05 - WL??0:00.00 (swi2: camnet) 017 0 0 -8 0 05 - WL??0:00.03 (swi3: cambio) 018 0 0 -52 0 05 - WL??0:00.00 (intr: acpi0) 019 0 0 -68 0 05 - WL??0:00.01 (intr: fxp0) 020 0 0 -64 0 05 - WL??0:00.00 (intr: ata0) 021 0 0 -64 0 05 - WL??0:00.00 (intr: ata1) 022 0 0 -64 0 05 - WL??0:00.00 (intr: uhci0) 023 0 0 8 0 05 usbevt DL??0:00.00 (usb0) 024 0 0 -60 0 05 - WL??0:00.00 (intr: atkbd0) 025 0 0 -48 0 05 - WL??0:00.01 (swi0: tty:sio) 026 0 0 -60 0 05 - WL??0:00.00 (intr: sio0) 027 0 0 -64 0 05 - WL??0:00.04 (intr: isp0) 066 1 0 96 0 1408 123 select Is??0:00.02 (inetd) 09066 1 96 0 1528 159 select Ss??0:00.05 (telnetd) 09190 0 8 0 1552 167 wait Isp00:00.05 (login) 4339291 0 8 0 1944 172 wait S p00:00.03 (sh) 4339692 1 96 0 1320 113 - R+p00:00.00 (ps) 0 7 1 0 5 0 1944 113 ttyin Is+ d00:00.07 (sh) $ ls -l total 18 -r--r--r-- 1 root wheel 4735 Oct 6 10:06 COPYRIGHT drwxr-xr-x 2 root wheel 1024 Oct 8 09:55 bin drwxr-xr-x 6 root wheel 512 Oct 7 22:04 boot drwxr-xr-x 3 root wheel 0 Oct 4 12:22 dev drwxr-xr-x 17 root wheel 2560 Oct 4 12:25 etc drwxr-xr-x 2 root wheel 512 Oct 5 19:22 mnt dr-xr-xr-x 1 root wheel 512 Oct 4 12:45 proc drwxr-xr-x 2 root wheel 512 Oct 6 10:06 root drwxr-xr-x 2 root wheel 2048 Oct 8 09:47 sbin lrwxr-xr-x 1 root wheel12 Oct 8 18:00 sys -> /usr/src/sys drwxr-xr-t 2 root wheel 512 Oct 4 12:28 tmp drwxr-xr-x 13 root wheel 512 Oct 8 09:30 usr drwxr-xr-x 19 root wheel 512 Oct 5 19:22 var $ Yes, this is running on real hardware, not a simulator. There is still lots to do, but there is definate progress! The loader interface looks like this (I have deliberately disabled all automatic startup features, so it's a tad rough): EFI Boot Manager ver 1.02 [12.38] Please select a boot option shell Leenucks Boot option maintenance menu Use ^ and v to change option(s). Use Enter to select an option Loading.: shell EFI Shell version 1.02 [12.38] Device mapping table fs0 : VenHw(Unknown Device:80)/HD(Part1,Sig) blk0 : Acpi(PNP0A03,0)/Pci(3|1)/Ata(Prima
options NO_KLD
Will this NO_KLD option be commited to -current and then hopefully -stable? I have been checking the LINT file each morning after the nightly cvsup runs hoping to find this option in there but so far havent seen it in sight. Any ideas? TIA Holt __ Do You Yahoo!? NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For your amusement..
If memory serves me right, Peter Wemm wrote: > Connected to ia64.wemm.org. > Escape character is '^]'. > > FreeBSD/ia64 (ia64.wemm.org) (ttyp0) That's totally awesome. Congratulations to all involved! Now, how long before I need to start worrying about release notes for the ia64? :-) Bruce. msg32397/pgp0.pgp Description: PGP signature
Re: For your amusement..
On Mon, Oct 08, 2001 at 12:09:41PM -0700, Bruce A. Mah wrote: > If memory serves me right, Peter Wemm wrote: > > > Connected to ia64.wemm.org. > > Escape character is '^]'. > > > > FreeBSD/ia64 (ia64.wemm.org) (ttyp0) > > That's totally awesome. Congratulations to all involved! > > Now, how long before I need to start worrying about release notes for > the ia64? :-) Only after the Release Note maintainers have been given a free-of-charge Itanium to verify things on? :) -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For your amusement..
On Mon, 08 Oct 2001 12:09:41 -0700 "Bruce A. Mah" <[EMAIL PROTECTED]> wrote: >If memory serves me right, Peter Wemm wrote: > >> Connected to ia64.wemm.org. >> Escape character is '^]'. >> >> FreeBSD/ia64 (ia64.wemm.org) (ttyp0) > >That's totally awesome. Congratulations to all involved! > >Now, how long before I need to start worrying about release notes for >the ia64? :-) > >Bruce. I make Bruce's words mine: Congratulations People, thats great :-) +---+-+ | Patrick Leandro Tracanelli do Carmo | ( ) | | RPGw/IRC Nick -- Eksffa Shyranui Kapwam | (O_O) | |Eeviac host FreeBSD 5.0-CURRENT Dual SMP @444Mhz | \`-'/ w| | 4o Ciclo (Fatorial) - Faculdade de Tecnologia de Taquaritinga | ( )__|| |===| /m`m\ | | [EMAIL PROTECTED] - Fone: (0xx55) 9972-9465 | FreeBSD | +---+-+ |Administrador de Redes e Sistemas | BSD Unix, System V & Open Source Syst| +---+-+ Long live Hanin Elias, Kim Deal!!! ~ ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For your amusement..
Amusement? Excitement you mean! :-) That's REALLY a significant milestone and the IA-64 is by no means a simple architecture to come to grips with. My hat is off (yet again) to Doug! I think that makes two 64 bit architecture ports he's now had a lot to do with. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For your amusement..
Doug, Peter, This is great news indeed :-). I assume there's much work to go, but very cool. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Mon, 8 Oct 2001, Peter Wemm wrote: > Just a FYI to people not on the ia64 list... > > All bow before Doug Rabson, the mighty! :-) > > peter@overcee[11:23am]~src/sys/ia64/compile/SMALL-203# telnet -K ia64 > Trying 10.0.0.21... > Connected to ia64.wemm.org. > Escape character is '^]'. > > FreeBSD/ia64 (ia64.wemm.org) (ttyp0) > > login: peter > Password: > Last login: Thu Oct 4 12:26:02 from overcee > Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 > The Regents of the University of California. All rights reserved. > > FreeBSD 5.0-CURRENT (SMALL) #1: Mon Oct 8 10:33:33 PDT 2001 > > Welcome to FreeBSD! > > $ uname -a > FreeBSD ia64.wemm.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Mon Oct 8 10:33:33 PDT >2001 [EMAIL PROTECTED]:/home/src/sys/ia64/compile/SMALL ia64 > $ df > Filesystem 1K-blocks UsedAvail Capacity Mounted on > /dev/da1a 254063 124581 10915753%/ > devfs 110 100%/dev > procfs 880 100%/proc > $ ps -axl > UID PID PPID CPU PRI NI VSZ RSS WCHAN STAT TT TIME COMMAND > 0 0 0 0 -16 0 05 sched DLs ??0:00.00 (swapper) > 0 1 0 0 8 0 1312 23 wait ILs ??0:00.01 (init) > 0 2 0 0 -16 0 05 psleep DL??0:00.00 (pagedaemon) > 0 3 0 0 20 0 05 psleep DL??0:00.00 (vmdaemon) > 0 4 0 0 20 0 05 pgzero DL??0:00.00 (pagezero) > 0 5 0 0 -16 0 05 psleep DL??0:00.01 (bufdaemon) > 0 6 0 0 20 0 05 syncer DL??0:00.03 (syncer) > 010 0 48 -16 0 05 - RL??7:59.29 (idle) > 011 0 0 -44 0 05 - WL??0:00.02 (swi1: net) > 012 0 0 -48 0 05 - WL??0:01.11 (swi6: tty:sio >clock) > 013 0 0 -32 0 05 - WL??0:00.00 (swi4: vm) > 014 0 0 76 0 05 sleep DL??0:00.04 (random) > 015 0 0 -28 0 05 - WL??0:00.00 (swi5: task >queue) > 016 0 0 -40 0 05 - WL??0:00.00 (swi2: camnet) > 017 0 0 -8 0 05 - WL??0:00.03 (swi3: cambio) > 018 0 0 -52 0 05 - WL??0:00.00 (intr: acpi0) > 019 0 0 -68 0 05 - WL??0:00.01 (intr: fxp0) > 020 0 0 -64 0 05 - WL??0:00.00 (intr: ata0) > 021 0 0 -64 0 05 - WL??0:00.00 (intr: ata1) > 022 0 0 -64 0 05 - WL??0:00.00 (intr: uhci0) > 023 0 0 8 0 05 usbevt DL??0:00.00 (usb0) > 024 0 0 -60 0 05 - WL??0:00.00 (intr: atkbd0) > 025 0 0 -48 0 05 - WL??0:00.01 (swi0: tty:sio) > 026 0 0 -60 0 05 - WL??0:00.00 (intr: sio0) > 027 0 0 -64 0 05 - WL??0:00.04 (intr: isp0) > 066 1 0 96 0 1408 123 select Is??0:00.02 (inetd) > 09066 1 96 0 1528 159 select Ss??0:00.05 (telnetd) > 09190 0 8 0 1552 167 wait Isp00:00.05 (login) > 4339291 0 8 0 1944 172 wait S p00:00.03 (sh) > 4339692 1 96 0 1320 113 - R+p00:00.00 (ps) > 0 7 1 0 5 0 1944 113 ttyin Is+ d00:00.07 (sh) > $ ls -l > total 18 > -r--r--r-- 1 root wheel 4735 Oct 6 10:06 COPYRIGHT > drwxr-xr-x 2 root wheel 1024 Oct 8 09:55 bin > drwxr-xr-x 6 root wheel 512 Oct 7 22:04 boot > drwxr-xr-x 3 root wheel 0 Oct 4 12:22 dev > drwxr-xr-x 17 root wheel 2560 Oct 4 12:25 etc > drwxr-xr-x 2 root wheel 512 Oct 5 19:22 mnt > dr-xr-xr-x 1 root wheel 512 Oct 4 12:45 proc > drwxr-xr-x 2 root wheel 512 Oct 6 10:06 root > drwxr-xr-x 2 root wheel 2048 Oct 8 09:47 sbin > lrwxr-xr-x 1 root wheel12 Oct 8 18:00 sys -> /usr/src/sys > drwxr-xr-t 2 root wheel 512 Oct 4 12:28 tmp > drwxr-xr-x 13 root wheel 512 Oct 8 09:30 usr > drwxr-xr-x 19 root wheel 512 Oct 5 19:22 var > $ > > Yes, this is running on real hardware, not a simulator. There is still > lots to do, but there is definate progress! > > The loader interface looks like this (I have deliberately disabled all > automatic startup features, so it's a tad rough): > > EFI Boot Manager ver 1.02 [12.38] > > Please select a boot option > > shell
Re: uucp @ sourceforge
[moved to -chat, since it has nothing to do with -current] On Mon, 08 Oct 2001 11:09:06 -0700, Terry Lambert wrote: > Maxim Sobolev wrote: > > > Sourceforge is based on the premise that you can create an > > > Open Source project by declaring one, which is untrue. If > > > you want my opnions in detail, check the -chat and -advocacy > > > archives. > > > > I am not sure how this could defeat the fact that you can get a necessary > > ftp/www/cvs/etc space easily. > > It doesn't defeat that. > > It only defeats the project living on after I am run over by > a bus, since the project will be unable to attract outside > participation if it is hosted at SourceForge. > > You can't cookie-cutter Open Source projects, at least not the > way they are trying to do it. I am sure that number of people involved in successful projects hosted at SF would be quite surprised hearing this. Personally I can name dozen on such projects, and I'm sure that it if only a fraction of the total number. It is not a magic bullet, granted, but it isn't a devil's seed either. Please don't get me wrong - I'm not trying to advocate SF, just trying to point out that such a black&white view is oversimplistic and things like SF have their own niche at current opensource landscape. If you don't like it, well that's your right - host elsewhere, but please don't try to substantiate your theories by throwing away facts that don't support them. > As I said before, you need to read my objections in the > -current and -advocacy lists. I'll take a look at them when I have a time. > Realize that I have participated in the genesis of no less > than 5 open source projects, 4 of which are still going. Ok, I've realised. :) -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Missing stack frames in kgdb/ddb traces
On Sun, Oct 07, 2001 at 09:32:56PM +0100, Ian Dowse wrote: > Index: gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c > === > RCS file: /dump/FreeBSD-CVS/src/gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c,v > retrieving revision 1.27 > diff -u -r1.27 kvm-fbsd.c > --- gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c 19 Sep 2001 18:42:19 - 1.27 > +++ gnu/usr.bin/binutils/gdb/i386/kvm-fbsd.c 7 Oct 2001 19:45:28 - > @@ -176,7 +176,7 @@ > return (read_memory_integer (fr->frame + 8 + oEIP, 4)); > > case tf_interrupt: > - return (read_memory_integer (fr->frame + 16 + oEIP, 4)); > + return (read_memory_integer (fr->frame + 12 + oEIP, 4)); Please commit, if this is tested. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMWare2 permission problems on -current as of Sep 26
No, I wan't using linux_kdump, thanks for the education. Today I've installed linux_kdump from the package on jp.current.freebsd.org, and now I get 1207 vmware CALL linux_access(0xbfbff759,0x4) 1207 vmware NAMI "/compat/linux/home/hunter/gwk/.Xauthority" 1207 vmware NAMI "/home/hunter/gwk/.Xauthority" 1207 vmware RET linux_access -1 errno 13 Permission denied which looks a little more meaningful (no negative errno any more, and a linux_* syscall is listed). Still needs debugging, which I'll attempt to do when I get a little time. -- Regards, Georg. At Sun, 7 Oct 2001 19:28:35 -0400 (EDT), Robert Watson wrote: > > > On Sun, 7 Oct 2001, Georg-W. Koltermann wrote: > > [...] > > I ran the vmware command through ktrace(1) (had to do that as root since > > it won't trace a SUID program for a normal user), and it does get an > > error return from an access(2) on .Xauthority: > > > > 1207 vmware CALL access(0xbfbff759,0x4) > > 1207 vmware NAMI "/compat/linux/home/hunter/gwk/.Xauthority" > > 1207 vmware NAMI "/home/hunter/gwk/.Xauthority" > > 1207 vmware RET access -1 errno -13 Unknown error: -13 > > > > It seems I am going to debug the access() call next. > > I'm a little surprised that they're calling access(). Are you using the > linux_kdump from the ports collection, btw? Otherwise the system calls > aren't listed right, due to differences in system call number. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > [EMAIL PROTECTED] NAI Labs, Safeport Network Services > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VMWare2 permission problems on -current as of Sep 26
So normally vmware runs setuid root, which means that the 'real' uid and gid will be the normal user, as opposed to the root user. '0x4' on FreeBSD would constitute R_OK -- a quick glance at my local Linux box demonstrates that it has the same meaning there. If you run the 'access' command with similar arguments on /home/hunter/gwk/.Xauthority, what do you get back? An interesting experiment might be to write a short program invoking access(2) with the same arguments, compiled under both ABIs, and then experimented with and without setuid-root. A glance at the linux_access() implementation looks right to me, but maybe there's something going on relating to preserving real/saved uids/gids and the process credential. Or alternatively, maybe your .Xauthority file isn't readable :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Mon, 8 Oct 2001, Georg-W. Koltermann wrote: > No, I wan't using linux_kdump, thanks for the education. > > Today I've installed linux_kdump from the package on > jp.current.freebsd.org, and now I get > > 1207 vmware CALL linux_access(0xbfbff759,0x4) > 1207 vmware NAMI "/compat/linux/home/hunter/gwk/.Xauthority" > 1207 vmware NAMI "/home/hunter/gwk/.Xauthority" > 1207 vmware RET linux_access -1 errno 13 Permission denied > > which looks a little more meaningful (no negative errno any more, and > a linux_* syscall is listed). > > Still needs debugging, which I'll attempt to do when I get a little > time. > > -- > Regards, > Georg. > > > At Sun, 7 Oct 2001 > 19:28:35 -0400 (EDT), Robert Watson wrote: > > > > > > On Sun, 7 Oct 2001, Georg-W. Koltermann wrote: > > > > [...] > > > I ran the vmware command through ktrace(1) (had to do that as root since > > > it won't trace a SUID program for a normal user), and it does get an > > > error return from an access(2) on .Xauthority: > > > > > > 1207 vmware CALL access(0xbfbff759,0x4) > > > 1207 vmware NAMI "/compat/linux/home/hunter/gwk/.Xauthority" > > > 1207 vmware NAMI "/home/hunter/gwk/.Xauthority" > > > 1207 vmware RET access -1 errno -13 Unknown error: -13 > > > > > > It seems I am going to debug the access() call next. > > > > I'm a little surprised that they're calling access(). Are you using the > > linux_kdump from the ports collection, btw? Otherwise the system calls > > aren't listed right, due to differences in system call number. > > > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > > [EMAIL PROTECTED] NAI Labs, Safeport Network Services > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: For your amusement..
In message <[EMAIL PROTECTED]>, Peter Wemm wrote: >Just a FYI to people not on the ia64 list... > >All bow before Doug Rabson, the mighty! :-) Great! >acpi0: on motherboard >acpi0: power button is handled as a fixed feature programming model. >Timecounter "ACPI" frequency 3579545 Hz >acpi_cpu0: on acpi0 >acpi_cpu1: on acpi0 >acpi_pcib0: port 0xcf8-0xcff on acpi0 If there are no problem, would you give me DSDT block? Takanori Watanabe http://www.planet.sci.kobe-u.ac.jp/~takawata/key.html";> Public Key Key fingerprint = 2C 51 E2 78 2C E1 C5 2D 0F F1 20 A3 11 3A 62 2A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do soft interrupt coelescing?
On Sun, Oct 07, 2001 at 00:56:44 -0700, Terry Lambert wrote: > "Kenneth D. Merry" wrote: > > [ I don't particularly want to get involved in this thread...but... ] > > > > Can you explain why the ti(4) driver needs a coalescing patch? It already > > has in-firmware coalescing paramters that are tuneable by the user. It > > also already processes all outstanding BDs in ti_rxeof() and ti_txeof(). > > > The answer to your question is that the card will continue to DMA > into the ring buffer, even though you are in the middle of the > interrupt service routine, and that the amount of time taken in > ether input is long enough that you can have more packets come in > while you are processing (this is actually a good thing). > > This is even *more* likely with hardware interrupt coelescing, > since the default setting is to coelesce 32 packets into a > single interrupt, meaning that you have up to 32 iterations of > ether input to call, and thus the amount of time spent processing > them actually affords *more* time for additional packets to come > in. As you say above, this is actually a good thing. I don't see how this ties into the patch to introduce some sort of interrupt coalescing into the ti(4) driver. IMO, you should be able to tweak the coalescing parameters on the board to do what you want. > In my own personal situation, I have also implemented Lazy > Receiver Processing (per the research done by Rice University > and in the "Click Router" project; no relation to "ClickArray"), > which does all stack processing at the hardware interrupt, rather > then queueing between the hardware interrupt and NETISR, so my > processing path is actually longer; I get more benefit from the > change than you would, but on a heavily loaded system, you would > also get some benefit, if you were able to load the wire heavily > enough. > > The LRP implementation should be considered by FreeBSD as well, > since it takes the connection rate from ~7,000/second up to > ~23,000/second, by avoiding the NetISR. Rice University did > an implementation in 2.2.x, and then another one (using resource > containers -- I recommend against this one, not only because of > license issues with the second implementation) for 4.2; both > sets of research were done in FreeBSD. Unfortunately, neither > implementation was production quality (among other things, they > broke RFC 1323, and they have to run a complete duplicate stack > as a different protocol family because some of their assumptions > make it non-interoperable with other protocol stacks). That sounds cool, but I still don't see how this ties into the patch you sent out. > > It isn't terribly clear what you're doing in the patch, since it isn't a > > context diff. > > It's a "cvs diff" output. You could always check out a sys > tree, apply it, and then cvs diff -c (or -u or whatever your > favorite option is) to get a diff more to your tastes. As Peter Wemm pointed out, we can't use non-context diffs safely without the exact time, date and branch of the source files. This introduces an additional burden for no real reason other than you neglected to use -c or -u with cvs diff. > > You also never gave any details behind your statement last week: > > "Because at the time the Tigon II was released, the jumbogram > > wire format had not solidified. Therefore cards built during > > that time used different wire data for the jumbogram framing." > > > > I asked, in response: > > > > "Can you give more details? Did someone decide on a different ethertype > > than 0x8870 or something? > > > > That's really the only thing that's different between a standard ethernet > > frame and a jumbo frame. (other than the size)" > > I believe it was the implementation of the length field. I > would have to get more information from the person who did > the interoperability testing for the autonegotiation (which > failed between the Tigon II and the Intel Gigabit cards). I > can assure you anecdotally, however, that autonegotiation > _did_ fail. I would believe that autonegotiation (i.e. 10/100/1000) might fail, especially if you're using 1000BaseT Tigon II boards. However, I would like more details on the failure. It's entirely possible that it could be fixed in the firmware, probably without too much trouble. I find it somewhat hard to believe that Intel would ship a gigabit board that didn't interoperate with the board that up until probably recently was probably the predominant gigabit board out there. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do soft interrupt coelescing?
* Kenneth D. Merry <[EMAIL PROTECTED]> [011009 00:11] wrote: > > As you say above, this is actually a good thing. I don't see how this ties > into the patch to introduce some sort of interrupt coalescing into the > ti(4) driver. IMO, you should be able to tweak the coalescing parameters > on the board to do what you want. No matter how hard you tweak the board, an interrupt may still trigger while you process a hardware interrupt, this causes an additional poll which can cause additional coalescing. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do soft interrupt coelescing?
> * Kenneth D. Merry <[EMAIL PROTECTED]> [011009 00:11] wrote: > > > > As you say above, this is actually a good thing. I don't see how this ties > > into the patch to introduce some sort of interrupt coalescing into the > > ti(4) driver. IMO, you should be able to tweak the coalescing parameters > > on the board to do what you want. > > No matter how hard you tweak the board, an interrupt may still > trigger while you process a hardware interrupt, this causes an > additional poll which can cause additional coalescing. I don't think I understand what sort of crack you are smoking. If an interrupt-worthy condition is asserted on the board, you aren't going to leave your typical interrupt handler anyway; this sort of coalescing already happens without any "help". -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do soft interrupt coelescing?
On Tue, Oct 09, 2001 at 00:18:57 -0500, Alfred Perlstein wrote: > * Kenneth D. Merry <[EMAIL PROTECTED]> [011009 00:11] wrote: > > > > As you say above, this is actually a good thing. I don't see how this ties > > into the patch to introduce some sort of interrupt coalescing into the > > ti(4) driver. IMO, you should be able to tweak the coalescing parameters > > on the board to do what you want. > > No matter how hard you tweak the board, an interrupt may still > trigger while you process a hardware interrupt, this causes an > additional poll which can cause additional coalescing. At least in the case of the Tigon, it won't interrupt while there is a '1' written in mailbox 0. (This happens in ti_intr().) Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Why do soft interrupt coelescing?
* Mike Smith <[EMAIL PROTECTED]> [011009 00:25] wrote:
> > * Kenneth D. Merry <[EMAIL PROTECTED]> [011009 00:11] wrote:
> > >
> > > As you say above, this is actually a good thing. I don't see how this ties
> > > into the patch to introduce some sort of interrupt coalescing into the
> > > ti(4) driver. IMO, you should be able to tweak the coalescing parameters
> > > on the board to do what you want.
> >
> > No matter how hard you tweak the board, an interrupt may still
> > trigger while you process a hardware interrupt, this causes an
> > additional poll which can cause additional coalescing.
>
> I don't think I understand what sort of crack you are smoking.
>
> If an interrupt-worthy condition is asserted on the board, you aren't
> going to leave your typical interrupt handler anyway; this sort of
> coalescing already happens without any "help".
After talking to you on IRC it's become obvious that this doesn't
exactly happen without help. It's more of a side effect of the
way _some_ of the drivers are written.
What I understand from talking to you:
Most smarter drivers or high performance ones will check if the
tx/rx rings have been modified by the hardware and will consume
those packets as well.
However, most drivers have code like this:
if (ifp->if_flags & IFF_RUNNING) {
/* Check RX return ring producer/consumer */
ti_rxeof(sc);
/* Check TX ring producer/consumer */
ti_txeof(sc);
}
Now if more packets come in while in ti_txeof() it seems that
you'll need to take an additional interrupt to get at them.
So Terry's code isn't wrong, but it's not as amazing as one
would initially think, it just avoids a race that can happen
while transmitting packets packets and more arrive or while
recieving packets and the transmit queue drains.
Now, when one is be doing a lot more work in the interrupt context
(or perhaps just running on a slower host processor), Terry's
patches make a lot more sense as there's a much larger window
available for this race.
The fact that receiving is done before transmitting (at least in
the 'ti' driver) makes it an even smaller race as you're less likely
to be performing a lengthy operation inside the tx routine than if
you were doing some magic in the rx routine with incomming packets.
Or at least that's how it seems to me.
Either way, no need to get your latex in a bunch Mike. :-)
--
-Alfred Perlstein [[EMAIL PROTECTED]]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
