Dreamweaver 2
Hi, my name is Robert. I came across your address while trying to find a crack for Dreamweaver 2.I've got to admit I'm pretty green at this sort of thing, so I guess I'm asking if you have or know where I can it. Also are there any programs for generating cracks, passwords and so on To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Comments above kmem_malloc() (vm/vm_kern.c)
Is the following comment above kmem_malloc()'s definition in: /sys/vm/vm_kern.c ... still valid? (I hope and suspect not): " * Note that this still only works in a uni-processor environment and * when called at splhigh(). " The only places, as far as I've seen, that call kmem_malloc are the kernel's malloc() and the mbuf allocation routines. Niether of these seems to do it at splhigh(), either. --Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dreamweaver 2
On Saturday, March 25, 2000, VR Dredge wrote: Hi, my name is Robert. I came across your address while trying to find a crack for Dreamweaver 2.I've got to admit I'm pretty green at this sort of thing, so I guess I'm asking if you have or know where I can it. Also are there any programs for generating cracks, passwords and so on Where did you get this address as a place to get cracks for Windows software? This mailing list is for general FreeBSD technical discussion. -- |Chris Costello [EMAIL PROTECTED] |All the simple programs have been written, and all the good names taken. ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
MikeM [EMAIL PROTECTED] wrote: Has anyone thought of Unicode support on FreeBSD? It has crossed my mind... I think that it is inevitable that eventually FreeBSD will *need* to support unicode if it wants to continue as a viable operating system in the future. Probably. The demand for Unicode support is currently rather limited, but I expect it to pick up somewhat once it is pervasive under Linux and applications programmers come to expect its availability. This means that it probably will need to be modified from the ground up. Not at all. Is there any way of implementing partial support, working in stages, untill it is fully supported? Just that. I suggest you read these documents: "UTF-8 and Unicode FAQ" by Markus Kuhn http://www.cl.cam.ac.uk/~mgk25/unicode.html "The Unicode HOWTO" by Bruno Haible ftp://ftp.ilog.fr/pub/Users/haible/utf8/Unicode-HOWTO.html "Unicode Fonts and Tools for X11" by Markus Kuhn http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html These are written for Linux but they are largely applicable to BSD in general and FreeBSD in particular, too. The practical relevance of Unicode has taken a huge leap forward when Thomas Dickey made xterm became capable of displaying UTF-8 encoded Unicode character streams and Markus Kuhn coordinated the creation of some suitable fonts. This work has been merged into XFree86 4.0. For those of us still relying on an older release or actually requiring an even newer version of xterm, I have made ports available: http://home.pages.de/~naddy/unix/freebsd/xterm.shar http://home.pages.de/~naddy/unix/freebsd/ucs-fixed.shar (Earlier versions of) these have been submitted in PRs #15545 and #15840, but for some reason they have never been committed. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unicode on FreeBSD
Christian Weisgerber wrote: (Earlier versions of) these have been submitted in PRs #15545 and #15840, but for some reason they have never been committed. don't give up. It's not immediatly who is responsible for this, but it's something that is generally considered an important future subject for freebsd development. But you just need to figure out who is the right 'sponsor'. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 --- X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Request for review (HW checksum patches)
I have a set of patches which allows offloading checksums to NICs which support it (right now, only the Alteon based cards). The patch is at http://www.freebsd.org/~jlemon/csum.patch. Note that the alpha bits are currently untested. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Shim Code #error needed
I've been burned about 6 times now by the shim device support becoming optional. Oh well, that's current. However, I was thinking that it would be nice if there was something simple to grep for to see what drivers still needed to be converted. What would people think of my adding the following to the shim using devices: cvs diff: Diffing . Index: amd.c === RCS file: /home/imp/FreeBSD/CVS/src/sys/pci/amd.c,v retrieving revision 1.3 diff -u -r1.3 amd.c --- amd.c 2000/01/14 03:39:30 1.3 +++ amd.c 2000/03/25 18:07:31 @@ -50,6 +50,10 @@ /* #define AMD_DEBUG0 */ /* #define AMD_DEBUG_SCSI_PHASE */ +#ifndef COMPAT_OLDPCI +#error "The amd device requires the old pci compatibility shims" +#endif + #include sys/param.h #include sys/systm.h At least this way you get a decent error message when it fails to work. Comments? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for review (HW checksum patches)
From: Jonathan Lemon [EMAIL PROTECTED] Date: Sat, 25 Mar 2000 13:35:53 -0600 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Request for review (HW checksum patches) X-Mailer: Mutt 1.0pre2i Delivered-to: [EMAIL PROTECTED] X-Loop: FreeBSD.org I have a set of patches which allows offloading checksums to NICs which support it (right now, only the Alteon based cards). The patch is at http://www.freebsd.org/~jlemon/csum.patch. This prompts a question on a related issue: there seems to be an increase in support of protocol operations on NICs (e.g., tickle/keep-alive support while the system is sleeping; IPSec; ...). Is there enough there to let us build a general mechanism for communication between stack and driver for this sort of thing (e.g., a "meta-data" slot in the packet header which points to an mbuf, or other structure, that contains the details)? We're currently trying to deal with this in Mac OS X, and it'd be nice to avoid having multiple wheels of different size and shape in the same source base. Regards, Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dreamweaver 2
On Sat, 25 Mar 2000, VR Dredge wrote: Hi, my name is Robert. I came across your address while trying to find a crack for Dreamweaver 2.I've got to admit I'm pretty green at this sort of thing, so I guess I'm asking if you have or know where I can it. Also are there any programs for generating cracks, passwords and so on You can download the dreamweaver 2 crack by installing FreeBSD and installing the /usr/ports/cracks/drmwvr2 port. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Mylex Support
A friend of mine (FreeBSD user, between ISP'S) would like to know if anybody is working on support for Mylex Flashpoint BT950. He has one and is willing to port the driver from either Linux or BSDI, but is unwilling to duplicate the effort if someone else already has this beast in hand. Thanks for your comments. Cheers, Colin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #792
unsubscribe freebsd-hackers freebsd-hackers-digest wrote: freebsd-hackers-digestSaturday, March 25 2000Volume 04 : Number 792 In this issue: Re: shell issue Re: top sorting error zsh compdef collection for FreeBSD Missing keyboard symbols Re: top sorting error 3.x - 4.x kernel config converter Re: zsh compdef collection for FreeBSD Re: Missing keyboard symbols Re: Missing keyboard symbols Re: zsh compdef collection for FreeBSD Re: Missing keyboard symbols Re: WaveLAN PCI Adapter Re: Possible bug in 3.4 Re: 3.x - 4.x kernel config converter Dreamweaver 2 Comments above kmem_malloc() (vm/vm_kern.c) Re: Dreamweaver 2 Re: Unicode on FreeBSD Re: Unicode on FreeBSD Request for review (HW checksum patches) Shim Code #error needed -- Date: Fri, 24 Mar 2000 12:19:32 -0800 From: Alfred Perlstein [EMAIL PROTECTED] Subject: Re: shell issue * Dungeonkeeper [EMAIL PROTECTED] [000324 10:03] wrote: Hi there, First of all: I want to apologise for my poor english. Today me and a few friends of mine discussed the shells' (well, shell is actualy one of: sh/bash/csh/tcsh... not tested for ksh) command line expansion routines, mainly because of a problem discovered by one of my friends. I'm not sure if this is something new... So, let me explain what he found. It seems that the shell wants to allocate enough memory to hold the entire command line when expanding all of the arguments and we can force it to allocate hudge ammount of memory with a tricky command like this: carnivoro# /bin/csh -c `cat /dev/urandom` (I use tcsh here (the carnivoro# prompt), but the same thing happens when testing with sh/bash/tcsh) In this situation, the shell tries to allocate enough memory to hold what it reads from /dev/urandom, because it must be passed as a command line argument to /bin/csh ( actually, any command will be ok ). So, the shell eats more and more memory (on my machine (3.4-STABLE) - 251 MB) before the kernel decided to take some action (like killing some processes... started by other users? system services? or... in my case... crash :). My friend said that he sent a mail to bugtraq describing this problem. Those who are interested can read it. I believe that the shells have a maximum command lenght, so... I'm trying now to make the shell use the same command lenght when expanding such commands. I think this is the best way to avoid this problem. Any ideas? Yes, that's a good idea, I'd file a problem report with send-pr and it will probably be addressed. thanks, - -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Date: Fri, 24 Mar 2000 20:04:21 + From: David Malone [EMAIL PROTECTED] Subject: Re: top sorting error On Fri, Mar 24, 2000 at 01:00:54PM -0500, Luke Hollins wrote: I don't know if this is specific to FreeBSD but I just noticed it when i picked o time in top: PID USERNAME PRI NICE SIZERES STATETIME WCPUCPU COMMAND 79364 root2 0 2696K 1636K select 8:23 0.00% 0.00% apache 235 mysql 2 0 13372K 6384K poll 361:14 0.15% 0.15% mysqld It seems to be an overflow problem - top was reilying on things fitting into a int, which were 64 bits long. It looks like someone ran into the problem before for the %cpu field, and fixed it in a different way. This patch below should fix it regardless of the type of the variable. It's for a file in /usr/src/usr.bin/top. David. - --- machine.c.origFri Mar 24 19:57:36 2000 +++ machine.c Fri Mar 24 19:58:17 2000 @@ -737,26 +737,26 @@ 4 /* stop */ }; +#define CMP(a,b) ( (a) == (b) ? 0 : (a) (b) ? -1 : 1 ) #define ORDERKEY_PCTCPU \ - - if (lresult = (long) PP(p2, p_pctcpu) - (long) PP(p1, p_pctcpu), \ - - (result = lresult 0 ? 1 : lresult 0 ? -1 : 0) == 0) + if ((result = CMP(PP(p2, p_pctcpu),PP(p1, p_pctcpu))) == 0) #define ORDERKEY_CPTICKS \ - - if ((result = PP(p2, p_runtime) - PP(p1, p_runtime)) == 0) + if ((result = CMP(PP(p2, p_runtime),PP(p1, p_runtime))) == 0) #define ORDERKEY_STATE \ - - if ((result = sorted_state[(unsigned char) PP(p2, p_stat)] - \ - -sorted_state[(unsigned char) PP(p1, p_stat)]) == 0) + if ((result = CMP(sorted_state[(unsigned char) PP(p2, p_stat)], \ +sorted_state[(unsigned char) PP(p1, p_stat)])) == 0) #define ORDERKEY_PRIO \ - - if ((result = PP(p2, p_priority) - PP(p1, p_priority)) == 0) + if ((result = CMP(PP(p2, p_priority),PP(p1, p_priority))) == 0) #define ORDERKEY_RSSIZE \ - - if ((result = VP(p2, vm_rssize) - VP(p1, vm_rssize)) == 0) + if ((result = CMP(VP(p2, vm_rssize),VP(p1, vm_rssize))) == 0) #define ORDERKEY_MEM \ - - if ( (result = PROCSIZE(p2) - PROCSIZE(p1)) == 0 ) + if ((result
Re: Request for review (HW checksum patches)
FWIW, Win2000 has a mechanism for dealing with what they call task offloading. If you decide to attack the problem, an inexpensive device you can use for testing is the 3C905B; it does IP+TCP checksums. Sam - Original Message - From: "Justin C. Walker" [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Saturday, March 25, 2000 12:49 PM Subject: Re: Request for review (HW checksum patches) From: Jonathan Lemon [EMAIL PROTECTED] Date: Sat, 25 Mar 2000 13:35:53 -0600 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Request for review (HW checksum patches) X-Mailer: Mutt 1.0pre2i Delivered-to: [EMAIL PROTECTED] X-Loop: FreeBSD.org I have a set of patches which allows offloading checksums to NICs which support it (right now, only the Alteon based cards). The patch is at http://www.freebsd.org/~jlemon/csum.patch. This prompts a question on a related issue: there seems to be an increase in support of protocol operations on NICs (e.g., tickle/keep-alive support while the system is sleeping; IPSec; ...). Is there enough there to let us build a general mechanism for communication between stack and driver for this sort of thing (e.g., a "meta-data" slot in the packet header which points to an mbuf, or other structure, that contains the details)? We're currently trying to deal with this in Mac OS X, and it'd be nice to avoid having multiple wheels of different size and shape in the same source base. Regards, Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mylex Support
On Sat, Mar 25, 2000 at 16:26:32 -0500, Colin wrote: A friend of mine (FreeBSD user, between ISP'S) would like to know if anybody is working on support for Mylex Flashpoint BT950. He has one and is willing to port the driver from either Linux or BSDI, but is unwilling to duplicate the effort if someone else already has this beast in hand. Thanks for your comments. You should talk to Justin Gibbs [EMAIL PROTECTED]. He has the hardware, and I think he has documentation, and he has been planning on doing a driver for a while. He hasn't gotten around to it yet, though, so he might be open to someone else doing a driver. Ken -- Kenneth Merry [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shim Code #error needed
On Sat, Mar 25, 2000 at 01:43:12PM -0700, Warner Losh wrote: I've been burned about 6 times now by the shim device support becoming optional. Oh well, that's current. However, I was thinking that it would be nice if there was something simple to grep for to see what drivers still needed to be converted. What would people think of my adding the following to the shim using devices: cvs diff: Diffing . Index: amd.c === RCS file: /home/imp/FreeBSD/CVS/src/sys/pci/amd.c,v retrieving revision 1.3 diff -u -r1.3 amd.c --- amd.c 2000/01/14 03:39:30 1.3 +++ amd.c 2000/03/25 18:07:31 @@ -50,6 +50,10 @@ /* #define AMD_DEBUG0 */ /* #define AMD_DEBUG_SCSI_PHASE */ +#ifndef COMPAT_OLDPCI +#error "The amd device requires the old pci compatibility shims" +#endif + #include sys/param.h #include sys/systm.h At least this way you get a decent error message when it fails to work. Comments? I like it. The new entry in UPDATING should help, but it's easy to forget and the current errors aren't very obvious. Don't bother with tx if you do it though. I've got a patch I'll probalby submit sometime today. It's running without COMPAT_OLDPCI right now, I just want to take a stab and adding bus_space support while I'm messing around with it. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shim Code #error needed
In message [EMAIL PROTECTED] Brooks Davis writes: : I like it. The new entry in UPDATING should help, but it's easy to : forget and the current errors aren't very obvious. Well, I *WROTE* the entry in UPDATING (or at least committed it, I can't recall now). The only person I can think of that should know better more than me would be Peter Wemm who committed the changes :-) : Don't bother with : tx if you do it though. I've got a patch I'll probalby submit sometime : today. It's running without COMPAT_OLDPCI right now, I just want to : take a stab and adding bus_space support while I'm messing around with : it. OK. I'll give things a couple of days then. I have all the pci ones marked in my local tree, and some of the isa ones. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shim Code #error needed
On Sat, Mar 25, 2000 at 05:04:11PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] Brooks Davis writes: : I like it. The new entry in UPDATING should help, but it's easy to : forget and the current errors aren't very obvious. Well, I *WROTE* the entry in UPDATING (or at least committed it, I can't recall now). The only person I can think of that should know better more than me would be Peter Wemm who committed the changes :-) I know you commited it. Actually, I wrote it. I wasn't suggesting that you should have read UPDATING. That would have been rather silly. I was really just saying that while the message in UPDATING will help, adding these #errors is a very good idea because just knowing about the problem isn't quite sufficient to avoid it. As both of use seem to have proved. ;-) -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for review (HW checksum patches)
In article local.mail.freebsd-hackers/2325232027$[EMAIL PROTECTED] you write: FWIW, Win2000 has a mechanism for dealing with what they call task offloading. If you decide to attack the problem, an inexpensive device you can use for testing is the 3C905B; it does IP+TCP checksums. Yes, unfortunately it doesn't handle fragments at all. I looked at the card specs when devising the interface, to make sure that the new interface will be able to handle various chips. I haven't changed the 3com driver though, as I didn't want to spend time trying to figure out what the chip actually does vs what the manual says it does. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for review (HW checksum patches)
In article local.mail.freebsd-hackers/[EMAIL PROTECTED] you write: From: Jonathan Lemon [EMAIL PROTECTED] Date: Sat, 25 Mar 2000 13:35:53 -0600 To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Request for review (HW checksum patches) X-Mailer: Mutt 1.0pre2i Delivered-to: [EMAIL PROTECTED] X-Loop: FreeBSD.org I have a set of patches which allows offloading checksums to NICs which support it (right now, only the Alteon based cards). The patch is at http://www.freebsd.org/~jlemon/csum.patch. This prompts a question on a related issue: there seems to be an increase in support of protocol operations on NICs (e.g., tickle/keep-alive support while the system is sleeping; IPSec; ...). Is there enough there to let us build a general mechanism for communication between stack and driver for this sort of thing (e.g., a "meta-data" slot in the packet header which points to an mbuf, or other structure, that contains the details)? The patches I have were designed to solve a single problem, just checksum offloading. There are enough bits left in the new flag field that you could use for something else, I don't know enough about what you'd want to do to say if it's enough for a general mechanism. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: shell issue
On Fri, 24 Mar 2000, Dungeonkeeper wrote: Hi there, First of all: I want to apologise for my poor english. Today me and a few friends of mine discussed the shells' (well, shell is actualy one of: sh/bash/csh/tcsh... not tested for ksh) command line expansion routines, mainly because of a problem discovered by one of my friends. I'm not sure if this is something new... So, let me explain what he found. It seems that the shell wants to allocate enough memory to hold the entire command line when expanding all of the arguments and we can force it to allocate hudge ammount of memory with a tricky command like this: carnivoro# /bin/csh -c `cat /dev/urandom` (I use tcsh here (the carnivoro# prompt), but the same thing happens when testing with sh/bash/tcsh) In this situation, the shell tries to allocate enough memory to hold what it reads from /dev/urandom, because it must be passed as a command line argument to /bin/csh ( actually, any command will be ok ). So, the shell eats more and more memory (on my machine (3.4-STABLE) - 251 MB) before the kernel decided to take some action (like killing some processes... started by other users? system services? or... in my case... crash :). My friend said that he sent a mail to bugtraq describing this problem. Those who are interested can read it. I tried this too: /bin/csh -c `cat /dev/urandom` My shell grew to around 260MB, then "bash: xrealloc: cannot reallocate 134217728 bytes (0 bytes allocated)" Then it exited to the logon prompt. The rest of the system didn't notice. Happened both as root and normal. I tried this with ridiculously 8GB swap (just for fun...). With 128MB swap, the system complained when the swap got full, but then only killed the shell, returning me to the logonprompt on that window. No other problems either. Leif I believe that the shells have a maximum command lenght, so... I'm trying now to make the shell use the same command lenght when expanding such commands. I think this is the best way to avoid this problem. Any ideas? Best regards: zethix What is worth doing is worth the trouble of asking somebody to do. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #792
Sam Samalin wrote: unsubscribe freebsd-hackers which part of the following didn't you understand? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message ... -- Ben Smithurst / [EMAIL PROTECTED] / PGP: 0x99392F7D To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for review (HW checksum patches)
On Sat, Mar 25, 2000 at 06:56:42PM -0600, Jonathan Lemon wrote: The patches I have were designed to solve a single problem, just checksum offloading. There are enough bits left in the new flag field that you could use for something else, I don't know enough about what you'd want to do to say if it's enough for a general mechanism. Which card(s) do your patches support? I have a 3Com 3CR990-TX (typhoon) which does both TCP checksumming and 3DES (for IPSec). I'd love to give it a try. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville [EMAIL PROTECTED] PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
syslogd stops logging - caught in the act
Let's solve this once and for all. I've run syslogd -d and sent output to a file and waited for the inevitable cessation of logging although syslogd is still running. (Refer PRs 2191 5548 6216 8847 8865 10553 and two or three threads in -isp and/or -questions earlier this year that summarised the problems and their scope but didn't reach the list archives) Now logging's stopped and I need to get it restarted again soon, but I'd like to collect some useful information first. I need help to do that. This has been reported for almost all -release and -stable versions since early 2.2, and it's been hard to pin down what circumstances cause it or to repeat it on unaffected machines. The common facts are that syslogd is running, using CPU, but nothing goes to the logs, not mark messages, logger messages, nothing. One exception: the logs dutifully rotate and log that they have rotated. Sending a sighup does not fix it, only completely killing and restarting syslogd gets it going. Unless this is done, it will continue with the same behaviour (running but not logging) until reboot. All past speculation as to the cause has been met with counterexamples. There are five freebsd machines that exhibit this problem which I only have access to for another couple of days, so if anyone is interested in solving this long-standing failure of syslogd please take this opportunity to work with me on it. These machines range from almost idle very vanilla 3.3R workstations with only sendmail running, up to 3.4-STABLE of january running many daemons and with reasonable load, for which reliable logging is critical. Replies to my email address would be appreciated. -- Regards, -*Sue*- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Request for review (HW checksum patches)
On Sat, Mar 25, 2000 at 09:25:33PM -0500, Keith Stevenson wrote: On Sat, Mar 25, 2000 at 06:56:42PM -0600, Jonathan Lemon wrote: The patches I have were designed to solve a single problem, just checksum offloading. There are enough bits left in the new flag field that you could use for something else, I don't know enough about what you'd want to do to say if it's enough for a general mechanism. Which card(s) do your patches support? I have a 3Com 3CR990-TX (typhoon) which does both TCP checksumming and 3DES (for IPSec). I'd love to give it a try. Right now, just the Alteon cards. Support for the 3Com-XL can probably be added without too much trouble. I don't see a driver for the 3Com-990 though, and I can't find a reference to it on the 3Com website, is this a new card? -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd-hackers-digest V4 #792
Ben, relax, the gentleman in question subscribed to freebsd-hackers-digest and confused that list with freebsd-hackers. i have sent him email explaining the situation. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: syslogd stops logging - caught in the act
I asked Sue to get a ktrace of the syslogd, and here's the output: 18869 syslogd 954045445.977145 PSIG SIGALRM caught handler=0x804b068 mask=0x0 code=0x0 18869 syslogd 954045445.977343 RET poll -1 errno 4 Interrupted system call 18869 syslogd 954045445.977366 CALL gettimeofday(0xbfbfc5f0,0) 18869 syslogd 954045445.977382 RET gettimeofday 0 18869 syslogd 954045445.977403 CALL setitimer(0,0xbfbfc5e8,0xbfbfc5d8) 18869 syslogd 954045445.977424 RET setitimer 0 18869 syslogd 954045445.977438 CALL old.sigreturn(0xbfbfc624) 18869 syslogd 954045445.977456 RET old.sigreturn JUSTRETURN 18869 syslogd 954045445.977476 CALL poll(0xbfbfc6f0,0x1,0x9c40) 18869 syslogd 954045475.987785 PSIG SIGALRM caught handler=0x804b068 mask=0x0 code=0x0 18869 syslogd 954045475.987859 RET poll -1 errno 4 Interrupted system call 18869 syslogd 954045475.987879 CALL gettimeofday(0xbfbfc5f0,0) 18869 syslogd 954045475.987895 RET gettimeofday 0 18869 syslogd 954045475.987917 CALL setitimer(0,0xbfbfc5e8,0xbfbfc5d8) 18869 syslogd 954045475.987938 RET setitimer 0 18869 syslogd 954045475.987952 CALL old.sigreturn(0xbfbfc624) 18869 syslogd 954045475.987969 RET old.sigreturn JUSTRETURN 18869 syslogd 954045475.987990 CALL poll(0xbfbfc6f0,0x1,0x9c40) 18869 syslogd 954045505.997954 PSIG SIGALRM caught handler=0x804b068 mask=0x0 code=0x0 18869 syslogd 954045505.998120 RET poll -1 errno 4 Interrupted system call The poll() calls are from libc/net/res_send, while the gettimeofday() calls are from the alarm handler (in syslogd). The res_send code does roughly the following: msec = (timeout calculated based on # of tries) repeat: poll(pfd, 1, msec); if (errno == EINTR) goto repeat; So what's happening here is it seems that after the # of tries grows to a certain point, the timeout being passed to poll() is larger than the timeout between calls to the SIGALRM handler. Since the poll() timeout is not reset, this leads to an infinite loop. In the traces above, the poll() timeout is 4msec (== 40 sec), and the alarm handler is called every 30 sec. The fix should probably be to change res_send.c so that it properly decrements it's timeout value after being interrrupted. -- Jonathan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Missing keyboard symbols
On Fri, 24 Mar 2000, Doug Barton wrote: Heh... You know, I started to type out something to the effect of, "... space bar. FreeBSD has been mapping the Space Bar to the Any key combination since about 1992 to get around the restrictions of modern PC keyboards." But I thought there was an outside chance that this was a serious question, and I didn't want to run the risk that the poor doofus would repeat that statement in front of someone with a clue... A serious question from Mr. Override? Uh yeah :) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RTLD thread safety
When I try to compile a simple multi threaded program using a wrapper around rfork (from linuxthreads port), I get the following core dump: ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:54 Investigation into code reveals that lazy resolution of symbols (using PLTs) was happening in multiple threads in the linker simultaneously. Also, the code in lockdflt.c is achieving mutual exclusion by blocking signals. This doesn't work on a SMP machine using kernel threads. What would be the right solution for this ? A new set of primitives registered using dllockinit or making the defaults SMP thread-safe ? I suppose the linuxthreads port works because it has been tested only with Linux executables and Linux executables don't use lazy resolution of symbols ? I'm just speculating here. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
