Re: UID Limit
On Wed, May 22, 2002 at 04:53:37PM -0700, Darren Pilgrim wrote: Peter Pentchev wrote: On Wed, May 22, 2002 at 04:27:12PM +0100, Jamie Heckford wrote: Hi, I was wondering if anyone would be able to tell me what the limit is on a UID? Ie what is the highest integer it can go up to. I suppose as well some applications have different values.. or am I completly wrong :) The functions that deal with user ID's take a parameter of type uid_t. The uid_t type is defined in sys/types.h as u_int32_t. Hence, at least theoretically, FreeBSD supports uid's in the range 0 to 4G-1. It supports them that high, yes, but I believe they wrap at 9. I believe you are thinking of pid's (process ID's), not uid's (user ID's). G'luck, Peter -- Peter Pentchev [EMAIL PROTECTED][EMAIL PROTECTED] PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence contradicts itself - or rather - well, no, actually it doesn't! msg34568/pgp0.pgp Description: PGP signature
Re: UID Limit
Peter Pentchev wrote: I believe you are thinking of pid's (process ID's), not uid's (user ID's). Yes, you're right. Serves me for trying to do email after a long night of hacking at perverse bit-twiddling scripts. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
§Ò¹ Part Time ÊÃéÒ§ÃÒÂä´é´Õ ãªéà·¤â¹âÅÂշӧҹ᷹¤Ø³
§Ò¹ Part Time ãªéà·¤â¹âÅÂշӧҹ᷹¤Ø³ äÁè¡ÃзºµèͪÕÇÔµ»ÃШÓÇѹ¢Í§¤Ø³ äÁèÇèҤس¨Ðà»ç¹ã¤Ã ¤Ø³µéͧ¡ÒçҹÍÂèÒ§¹ÕéËÃ×Íà»ÅèÒ ?? - âÍ¡ÒÊ·Õè¨Ðà»ç¹à¨éҢͧ¡Ô¨¡ÒÃẺ§èÒ æ - ÁÕ¸ØáԨ¢Í§µ¹àͧº¹ Internet ( E-Commerce ) - à»Ô´´Óà¹Ô¹§Ò¹µÅÍ´ 24 ªÑèÇâÁ§µèÍÇѹ 7ÇѹµèÍÊÑ»´ÒËì 365Çѹã¹Ë¹Ö觻ÕäÁèÁÕÇѹËÂØ´ - à§Ô¹Å§·Ø¹µèÓ ÃÒÂä´éÊÙ§ Part Time 15,000 ºÒ·¢Öé¹ä»µèÍà´×͹ / Full Time 45,000 ºÒ·¢Öé¹ä» - äÁèµéͧ¨éÒ§¾¹Ñ¡§Ò¹¢Ò äÁèµéͧ»Ç´ËÑÇàÃ×èͧ¢Ö鹤èÒáç ¡ÒùѴËÂØ´§Ò¹ áÅÐäÁèµéͧ¨èÒÂÊÇÑÊ´Ô¡Òà - ãªéà·¤â¹âÅÂշӧҹ᷹¤Ø³ äÁè¡ÃзºµèÍ¡ÒôÓà¹Ô¹ªÕÇÔµ»ÃШÓÇѹ¢Í§¤Ø³ à¾Õ§á¤èÇѹÅÐ 2-3 ªÑèÇâÁ§ - ·Ó§Ò¹¨Ò¡·Õèä˹¡çä´é áµèÊÒÁÒöÁÕ¸ØáԨä´é·ÑèÇâÅ¡ - äÁèµéͧ¡Ñ¡µØ¹ÊÔ¹¤éÒ äÁèàÊÕ觵èͷع¨Á - ÁÕÃкº¨Ñ´Êè§ÊÔ¹¤éÒ ·Ñé§ã¹áÅеèÒ§»ÃÐà·È - äÁèãªè¡Òà Knock Door ¢ÒÂÊÔ¹¤éÒ áµèÅÙ¡¤éÒ¨ÐÇÔè§à¢éÒÁÒËҤس ÏÅÏ ¶éҤسÍÂÒ¡ÁÕ¡Ô¨¡ÒâͧµÑÇàͧáÅÐÂѧÊÒÁÒöãªéàÇÅÒÊèǹãËè¡ÑºÊÔ觷Õè¤Ø³ªÍº ¤Ø³·Óä´éá¹è¹Í¹ ¾ºàÃÒä´é·Õè¹Õè http://www.thaiworkathome.com/win â·Ã 0-2277-7850 µèÍ 57 ==¤Ø³ÍÒ¨ã¹ä´é¾ºã¹ÊÔ觷Õè¤Ø³ËÒÁҹҹ㹪ÕÇÔµ¡Ò÷ӧҹ== ¢ÍÍÀÑÂËÒ¡¤Ø³äÁèµéͧ¡ÒÃáµèä´éÃѺ mail ¹Õé ËÒ¡äÁèµéͧ¡ÒÃÃѺ¢èÒÇÊÒèҡàÃÒÍÕ¡ ¡ÃØ³Ò CLICK ä»·Õè http://www.thaiworkathome.com/unsubscribe.asp ¡ÃÍ¡ email-address ¢Í§·èÒ¹ áÅÐ submit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
§Ò¹ Part Time ÊÃéÒ§ÃÒÂä´é´Õ ãªéà·¤â¹âÅÂշӧҹ᷹¤Ø³
§Ò¹ Part Time ãªéà·¤â¹âÅÂշӧҹ᷹¤Ø³ äÁè¡ÃзºµèͪÕÇÔµ»ÃШÓÇѹ¢Í§¤Ø³ äÁèÇèҤس¨Ðà»ç¹ã¤Ã ¤Ø³µéͧ¡ÒçҹÍÂèÒ§¹ÕéËÃ×Íà»ÅèÒ ?? - âÍ¡ÒÊ·Õè¨Ðà»ç¹à¨éҢͧ¡Ô¨¡ÒÃẺ§èÒ æ - ÁÕ¸ØáԨ¢Í§µ¹àͧº¹ Internet ( E-Commerce ) - à»Ô´´Óà¹Ô¹§Ò¹µÅÍ´ 24 ªÑèÇâÁ§µèÍÇѹ 7ÇѹµèÍÊÑ»´ÒËì 365Çѹã¹Ë¹Ö觻ÕäÁèÁÕÇѹËÂØ´ - à§Ô¹Å§·Ø¹µèÓ ÃÒÂä´éÊÙ§ Part Time 15,000 ºÒ·¢Öé¹ä»µèÍà´×͹ / Full Time 45,000 ºÒ·¢Öé¹ä» - äÁèµéͧ¨éÒ§¾¹Ñ¡§Ò¹¢Ò äÁèµéͧ»Ç´ËÑÇàÃ×èͧ¢Ö鹤èÒáç ¡ÒùѴËÂØ´§Ò¹ áÅÐäÁèµéͧ¨èÒÂÊÇÑÊ´Ô¡Òà - ãªéà·¤â¹âÅÂշӧҹ᷹¤Ø³ äÁè¡ÃзºµèÍ¡ÒôÓà¹Ô¹ªÕÇÔµ»ÃШÓÇѹ¢Í§¤Ø³ à¾Õ§á¤èÇѹÅÐ 2-3 ªÑèÇâÁ§ - ·Ó§Ò¹¨Ò¡·Õèä˹¡çä´é áµèÊÒÁÒöÁÕ¸ØáԨä´é·ÑèÇâÅ¡ - äÁèµéͧ¡Ñ¡µØ¹ÊÔ¹¤éÒ äÁèàÊÕ觵èͷع¨Á - ÁÕÃкº¨Ñ´Êè§ÊÔ¹¤éÒ ·Ñé§ã¹áÅеèÒ§»ÃÐà·È - äÁèãªè¡Òà Knock Door ¢ÒÂÊÔ¹¤éÒ áµèÅÙ¡¤éÒ¨ÐÇÔè§à¢éÒÁÒËҤس ÏÅÏ ¶éҤسÍÂÒ¡ÁÕ¡Ô¨¡ÒâͧµÑÇàͧáÅÐÂѧÊÒÁÒöãªéàÇÅÒÊèǹãËè¡ÑºÊÔ觷Õè¤Ø³ªÍº ¤Ø³·Óä´éá¹è¹Í¹ ¾ºàÃÒä´é·Õè¹Õè http://www.thaiworkathome.com/win â·Ã 0-2277-7850 µèÍ 57 ==¤Ø³ÍÒ¨ã¹ä´é¾ºã¹ÊÔ觷Õè¤Ø³ËÒÁҹҹ㹪ÕÇÔµ¡Ò÷ӧҹ== ¢ÍÍÀÑÂËÒ¡¤Ø³äÁèµéͧ¡ÒÃáµèä´éÃѺ mail ¹Õé ËÒ¡äÁèµéͧ¡ÒÃÃѺ¢èÒÇÊÒèҡàÃÒÍÕ¡ ¡ÃØ³Ò CLICK ä»·Õè http://www.thaiworkathome.com/unsubscribe.asp ¡ÃÍ¡ email-address ¢Í§·èÒ¹ áÅÐ submit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Bad TCP checksum
Hi everyone, I'm experiencing something weird with my 4.6-RC box (compile of May 18). What happens is that for some hosts it just won't calculate the checksum properly, and thus my box is unable to start TCP connections to those hosts. Here's a piece of the output of tcpdump: 19:16:55.759657 me.50441 somehost.http: S [bad tcp cksum fffe!] 2079216431:2079216431(0) win 65535 mss 1452,nop,wscale 1,nop,nop, timestamp 797082 0 (DF) [tos 0x10] (ttl 96, id 41580, len 60) Additional info that might help: The default route goes through the tun0 interface, my ADSL service uses PPPoE and therefore I cannot think of any other way to work it out on FreeBSD. ppp(8) was compiled in the same day as the kernel, and I tried unloading firewalling and nothing different occured (at least apparently). NAT is disabled here. Since I saw once something similar happening, I think it's good to mention that these lines exist in my /etc/make.conf: CFLAGS= -O2 COPTFLAGS+= -O2 CPUTYPE=k6-2 They're in accordance with my K6-2 box. Just mentioned that because once I saw a box unable to connect to some hosts because it was a Pentium II with the kernel compiled for K6-2 boxes. What should I do? Please, CC any replies to me too, because I'm not subscribed to the lists. If any other output/detail is necessary, please ask away. Thank you very much in advance, Fred -- I'd love to go out with you, but I never go out on days that end in `Y.' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bad TCP checksum
On 2002.05.23 11:18:03 +, Fred Souza wrote: Since I saw once something similar happening, I think it's good to mention that these lines exist in my /etc/make.conf: CFLAGS= -O2 COPTFLAGS+= -O2 CPUTYPE=k6-2 I think you might get these kinds of problems with -O2. Try compiling the kernel with just -O and see if it fixes things. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 4.6-RC, Dell PowerEdge 4600, PCI boot-time bus walk
On Mon, 20 May 2002, Damon Anton Permezel wrote: 4.6-RC (which I am assuming is release candidate) still doesn't walk the entire PCI bus and find all devices for a Dell Poweredge 4600. Below, interested parties will be able to peruse the `boot -v' results, followed by `scanpci -v1'. I have a single Qlogic F/C card plugged into one of the PCI/X slots. This is a bit dated but I want to put in another prod on this since it came up recently. What is the status of PCI-X support on FreeBSD? Does it require anything beyond standard PCI support? If so, who's working on it? Hardware is now out there ... :-) Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/kern kern_fork.c
[The reference is ancient but I think it's still relevant.] On Mon, Feb 18, 2002 at 07:15:28PM -0800, Mike Silbersack wrote: silby 2002/02/18 19:15:28 PST Modified files: sys/kern kern_fork.c Log: A few misc forkbomb defenses: ... - Remove the printing of proc: table full. When the table really is full, this would flood the screen/logs, making the problem tougher to deal with. I've bumped into a similar problem when running StarOffice on a system without _KPOSIX_PRIORITY_SCHEDULING. It seems that StarOffice likes calling sched_yield() and doesn't take ENOSYS as a hint. My syslog entries showed repeat counts in the high 5-figure region. It's useful to know that a process wants to use the RT scheduling functions, but it would be nice if this message could be rate-limited so that processes that ignore return codes won't flood the console. I'm not sure how to achieve this - since doing it properly implies additional per-process state - and I don't think it's important enough to bloat struct proc. [I don't have the RT extensions enabled because there was a past thread about them being susceptable to priority inversion deadlocks - is this still true]. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[therman@lsil.com: 3rd party drivers]
- Forwarded message from Herman, Thomas [EMAIL PROTECTED] - Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] From: Herman, Thomas [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: 3rd party drivers Date: Thu, 23 May 2002 17:08:28 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) List-ID: freebsd-questions.FreeBSD.ORG List-Archive: http://docs.freebsd.org/mail/ (Web Archive) List-Help: mailto:[EMAIL PROTECTED]?subject=help (List Instructions) List-Subscribe: mailto:[EMAIL PROTECTED]?subject=subscribe%20freebsd-questions List-Unsubscribe: mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-questions X-Loop: FreeBSD.ORG Precedence: bulk X-UIDL: 01b8d72891804f7d8990f3f8e66d608a X-jf: 20020519, 1:1,2:1,3:1,4:1,ad:1,bo:1,di:1,do:1,he:1,ip:1,us:0 To whom it may concern, I'm inquiring about how to go about installing a driver from a floppy disk. We're developing a driver for the IDE controllers and we do not wish to submit the source code to the public domain. Does FreeBSD support 3rd party driver disks? Thank you, Thomas J. Herman LSI Logic Corporation 6145-D Northbelt Parkway Norcross, Georgia 30071 PH: (678) 728-1356 E-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message - End forwarded message - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/kern kern_fork.c
I've bumped into a similar problem when running StarOffice on a system without _KPOSIX_PRIORITY_SCHEDULING. It seems that StarOffice likes calling sched_yield() and doesn't take ENOSYS as a hint. My syslog entries showed repeat counts in the high 5-figure region. All such messages should just be removed, I'll try to sneak some time in and do it. Thanks for the info. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
problem with new eventhandler.h
I believe that the new eventhandler.h is depending on newer compiler tools. This makes it somewhat difficult to bootstrap. Can you make it so it *doesn't* require gcc3 installed? cam/cam_xpt.c In file included from ../../../sys/conf.h:48, from ../../../cam/cam_xpt.c:38: ../../../sys/eventhandler.h:95: badly punctuated parameter list in `#define' ../../../sys/eventhandler.h:137: badly punctuated parameter list in `#define' *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[no subject]
I know this is not about freebsd but i have noticed you guys are quit good at C and i am a new learner of the language. I am codeing a number guessing game all you do is pick a number between 1 and 136.. Now the problem is when the player answers it correctly it ouputs would you like to play again.. When it prompts for your answer it automaicly acwers it self.I figured out why it does is becuse there a values still in the keyboard buffer so i used fflush(stdin); to get rid of them but fflush(stdin); did not work so i put in an extra scanf statement right before the printf and scanf so it looks like this: scanf(%c, qNa); printf(WOULD YOU LIKE TO PLAY AGAIN?(y/n)); scanf(%c, qNa); is there anyone that might know why the fflush did not work I fugre this works besuse it shoves an empty vale into the buffer thus casuseing it to be empty. Dan _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: your mail
On May 23, echo dev wrote: is there anyone that might know why the fflush did not work I fugre this works besuse it shoves an empty vale into the buffer thus casuseing it to be empty. From the C-FAQ - http://www.eskimo.com/~scs/C-faq/top.html 12.26: How can I flush pending input so that a user's typeahead isn't read at the next prompt? Will fflush(stdin) work? A: fflush() is defined only for output streams. Since its definition of flush is to complete the writing of buffered characters (not to discard them), discarding unread input would not be an analogous meaning for fflush on input streams. There is no standard way to discard unread characters from a stdio input stream, nor would such a way necessarily be sufficient, since unread characters can also accumulate in other, OS-level input buffers. You may be able to read and discard characters until \n, or use the curses flushinp() function, or use some system-specific technique. See also questions 19.1 and 19.2. References: ISO Sec. 7.9.5.2; HS Sec. 15.2. -Clint To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/kern kern_fork.c
Peter Jeremy wrote: [I don't have the RT extensions enabled because there was a past thread about them being susceptable to priority inversion deadlocks - is this still true]. You are succeptible to such deadlocks no matter what. Priority inversion deadlock only occur in the spin case anyway, where the higher priority process is scheduled to run because it's runnable, rather than waiting pending the release of a contended resource. Basically, this only happens if the wait ends up being in user space, which makes it a coding error, and not a kernel problem (e.g. the high priority process is spinning on a resource availability which will never happen because the spinning process never gives the lower priority process a chance to run so that it can release its lock on the contended resource). This is the result of bad design. The only sure cures are priority lending (which can't fix a logic error), resource preemption (which requires a rewrite of a lot of code), resource precommit (Djikstra's Banker's Algorithm, which overcommits unnecessarily), and avoiding the problem in the first place (which would, again, require a rewrite of a lot of code). So disabling the RT extensions isn't going to save you from deadlocks. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ip src address in outgoing ipv4 multicast packets
* Rob ([EMAIL PROTECTED]) [020522 20:30]: I was just wondering why the src address is set to the host group in outgoing multicast packets on RELENG_4? As far as I can tell, rfc1054 says that the src address should be set to that of the host, not the host group (6.2). The behavior exists in 4.5-release also. I noticed this because linux seems to reject mc packets with a multicast source address (which is also incorrect according to section 7.2). Looking at the source, it seems trivial to get the correct (?) behavior. Is there some reason why we shouldn't do this? If anyone cares I just submitted a pr with an attached patch which will fix this problem. What is a good avenue to get this incorporated into the main tree? http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/38473 -r To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
