debugging a proc's kernel stack...
Hi, I want to see where some a deadlock is occurring in the kernel. I've got a dump with a bunch of processes in the inode or namecache state. Can anybody give me a hint about how to find a proc's "kernel stack" - so that I can find out what these kernel was doing for these processes when it locked up... (see "repeated deadlocks in FS ..." on the smp list for more info about the problem)... thanks alot, greg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
cache-friendly scheduling for SMP
I'm trying to run 1-2 processes with very large memory footprints on my P2 SMP machine. I'm finding that the process switches cpu's quite often, which obviously isn't good for the caches on the CPU. Can anybody point me to a paper, mailing list discussion, etc. that discusses scheduling processes to not thrash the cpu caches? Or if there's anything in place, how I can take advantage of it, etc. I got stumped on the idea a while ago, so I'm really curious... thanks, Greg To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
debugging a proc's kernel stack...
Hi, I want to see where some a deadlock is occurring in the kernel. I've got a dump with a bunch of processes in the inode or namecache state. Can anybody give me a hint about how to find a proc's "kernel stack" - so that I can find out what these kernel was doing for these processes when it locked up... (see "repeated deadlocks in FS ..." on the smp list for more info about the problem)... thanks alot, greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cache-friendly scheduling for SMP
I'm trying to run 1-2 processes with very large memory footprints on my P2 SMP machine. I'm finding that the process switches cpu's quite often, which obviously isn't good for the caches on the CPU. Can anybody point me to a paper, mailing list discussion, etc. that discusses scheduling processes to not thrash the cpu caches? Or if there's anything in place, how I can take advantage of it, etc. I got stumped on the idea a while ago, so I'm really curious... thanks, Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux executable picks up FreeBSD library over linux one and breaks
I had a Linux shared library problem on NetBSD that I think it might be helpful to mention. thunderbird (and firefox) set LD_LIBRARY_PATH to pick up their own modules. When acroread is invoked to display a pdf attachment, LD_LIBRARY_PATH is still set, and this causes acroread to read a BSD library. My workaround is to use a script for acroread that cleans the environment. I think this is a thunderbird bug; the environment of invoked programs should match the environment as of thunderbird's invocation. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: cvs question
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Aryeh > M. Friedman > I maintain a local repo of the via the cvs mode of cvsup. > When I do a: > > cvs -q -d /home/ncvs update > > It will update any modified files but will not add any new > files (it removes stale ones), but if I do a checkout it > overwrites my local modifications... any way to automatically > add new files but preserve local mods? Hi Aryeh, Give this a try: cvs -q -d /home/ncvs update -d The -d option given to the update subcommand builds directories the way cvs checkout does. Without it, update will only operate on directories that are already in your sandbox. Regards, Greg Larkin SourceHosting.net, LLC http://www.sourcehosting.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strdup(NULL) supposed to create SIGSEGV?
On 2008-04-23, Simun Mikecin wrote: > According to Open Group strdup should return NULL and set errno. Look at: > http://www.opengroup.org/onlinepubs/009695399/functions/strdup.html If you're going to quote documents to support your ideas, it's probably better to read them first. That document gives only lack of memory as a reason for failure. It does not state clearly, but clearly requires, correct behaviour from the caller who is required to provide a string argument. NULL is not a string, so the behaviour of the function is undefined. Basic C programming requires people not to step into the wilderness of undefined behaviour. > There is no valid argument for doing segfault instead of above behavior. If you can find an alternative that is not actually wrong, then by all means share it. To me, it seems like a good choice. Clearly, I am not alone. Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sysinstall is still inadequate after all of these years / sorry I started flame war
On 2008-07-03, Rob Lytle wrote: > > You can get rid of the nag screens by putting "BATCH=yes" into > > /etc/make.conf. (Not that this negates your other points.) > > What the hell does "yes" mean? That all option boxes are checked, or none > at all? I have never seen this explained anywhere. Instead of all this vociferous whining, how about just doing a bit of reading of the documentation? The ports(7) page might be a place to start. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: request for testers - xen support for domU in head
Kip Macy wrote: > Basic Xen support for 32-bit in PAE mode is in CVS. Please see the > wiki for general information: > > http://wiki.freebsd.org/FreeBSD/Xen > > Please be forewarned that I am not claiming that this is > production-ready. There are many known limitations. If you would like > to take it for a test drive and report bugs please give it a spin. > > Thanks, > Kip > Hi Kip, Thanks very much for the effort here. I'm looking forward to trying it out and providing feedback. I'm not really familiar with Xen, but perhaps enough to ask this question: Does this mean that Amazon EC2 will be able to boot FreeBSD instances? Thank you, Greg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Anyone try the new dual-head G-400 drivers?
On Thursday, 17 August 2000 at 11:13:35 -0400, thomas r stromberg wrote: >We're looking at buying some workstations for our network admins >here, and dual head is a plus. We were looking at buying them from >hardware.bsdi.com, and then today on Slashdot I saw: > >- >Matrox has released a beta driver for their G200/G400/G450 which >includes support for DualHead and QuadHead (up to 4 monitors), Flat >Panel and TV out. This driver is a beta. You can get it here and I >mirrored it here. You'll need XFree 4.0.1 in order to use this >driver. Please follow the readme file carefully! (the readme file >from Matrox's FTP needs to be converted dos2unix). Note: you cannot >use the 3D hardware acceleration on the 2nd monitor (yet). >- > >And of course, I was instantly happy when I saw this.. I'd be even happier if I knew where "here" was. >Has anyone tried these drivers yet in FreeBSD? No, but I'd like to. I have finally installed XFree 4.0 on my machine, and now have the board working in single-head mode, but it would be nice to get the second one working too. >They look to be the OS-independant XFree86 4.0.1 modules (nothing >funky like the NVIDIA ones). They come with some source code, but >it appears to be wrappers around a missing HAL (?) library, >though I could be wrong. I don't think you are. This was very much the intention. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Document about threads
>From: "Bryan K. Ogawa" <[EMAIL PROTECTED]>
>
>If anyone who knows about the state of the FreeBSD threads implementation
>could go through it and check it for factual errors, missing bits, etc.
>then that would be great.
in your section about common reentrant extensions, you mention the IPv6
apis. these are currently _not_ a viable alternative to the missing
traditional gethostby{name,addr}_r entrypoints due to a bug in KAME. they
are not threadsafe. your process will deadlock if multiple threads call
getipnodeby{addr,name}. see http://orange.kame.net/dev/query-pr.cgi?pr=277.
--
-greg
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: remote gdb debugging
On Monday, 28 August 2000 at 22:28:29 -0400, Christopher Stein wrote: > > Hello, > > I have been trying to connect to a remote gdb debug session via a serial > port (null modem cable) and can't seem to get the device right. I've tried > the devices: > > /dev/ttyd* > /dev/cuaa0 (as suggested by the freebsd handbook). > > hhmmm.. any suggestions? /dev/ttyd1 worked for a 3.3/4.0-pre install in > the past, but doesn't work for this new system, which is quite similar. Nothing has changed between 4.0 and now. I've had the devil's own job in the past, and I suspect you've hit a different problem. Do you have a breakout box on the line? If so, what's it showing? Also, you've set the sio flags correctly (0x80 or 0x90) on the debugged machine, right? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb remote connection
On Friday, 1 September 2000 at 14:18:25 -0400, Christopher Stein wrote: > > Hi, I discovered the source of my problem and solved it. For those > interested, here is an explanation: > > The flags of the serial I/O device to be used for remote debugging > needs to be changed in the config file. I told you this a while ago. You can also set them with UserConfig or in the loader configuration. > I plugged a null modem cable across the two ports labeled 1 (the > other one labeled 2) on the back of the computer. I assumed that > these correspond to serial port 1 as the FreeBSD kernel sees the > world (wrong assumption). Therefore, I only changed the permissions > of sio0 in the config file. You can't change permissions in the config file. What did you really do? > I was able to communicate across the serial line using device > /dev/cuaa1 and doing things like echo "hello" > /dev/cuaa1. /dev/cuaa1 isn't sio0. It's sio1. > GDB, however, was unable to establish a remote connection when I did > "target remote /dev/cuaa1" in kgdb. I started wondering about why > the device has the number "1" and not "0". So I decided to change > the permissions of sio1 in addition. It works! Yes, that's reasonable. > So it turns out the FreeBSD maps the physically labelled > (i.e. etched in metal) port 2 to sio0 and port 1 to sio1! No, this is completely incorrect. First, what's etched in metal has nothing to do with the matter. Secondly, the first serial port is sio0. The second serial port is sio1. If this is different on your computer, then that's where the problem lies. This is all described in the man page, of course: sio(4). Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Vinum RAID-5 performance problem
ne. Well, using master and slave together isn't fine in my book. > I just recently tried a similar setup using Promise Ultra66 controllers > with some Quantum and IBM drives (tried both). I got lousy performance > doing sustained writes to a RAID5 volume, using 4 UDMA66 drives each a > master on a controller. just doing a cat /dev/zero > blah > > I just decided to stick with striping and make regular backups. > I may try vinum with RAID5 on a SCSI array later. > > FWIW, > FreeBSD 4.1-STABLE > Abit BP6 dual 466 Celerons > (not using the HPT controller) > Promise Ultra66 > Quantum KA 13.6 gig and IBM Deskstar 30 gig drives Again, it would be nice to see some real figures. Why aren't you using the onboard controller on the BP6? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: help debugging kernel crash dump
On Wednesday, 13 September 2000 at 4:12:14 -0700, kts wrote: > Hi > > Just wanted to see if anyone could give me some feedback as to what > happened, or how to get more info. My machine was just sitting on > the LAN and it panic'd. X was running and it had some ssh's open. > > I'm running 4-STABLE from August 3rd. > > IdlePTD 3522560 > initial pcb at 2ce300 > panicstr: page fault > panic messages: > --- > > dumping to dev #wd/0x20001, offset 278560 > dump ata0: resetting devices .. done > 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 > 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 > 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 > --- > #0 0xc0141ef0 in boot () > (kgdb) bt > #0 0xc0141ef0 in boot () > #1 0xc014228d in panic () > #2 0xc025b166 in trap_fatal () > #3 0xc025ae19 in trap_pfault () > #4 0xc025a9df in trap () > #5 0xc01acb69 in fr_makefrip () > #6 0xc01b2a98 in fr_checkicmpmatchingstate () > #7 0xc01b2cd9 in fr_checkstate () > #8 0xc01ad758 in fr_check () > #9 0xc01a17e8 in ip_output () > #10 0xc019fa6a in icmp_send () > #11 0xc019f9eb in icmp_reflect () > #12 0xc019f314 in icmp_error () > #13 0xc01aa46e in udp_input () > #14 0xc01a0498 in ip_input () > #15 0xc01a050b in ipintr () > #16 0xc024de85 in swi_net_next () > Cannot access memory at address 0x531b6b24. > (kgdb) > > any way I can get more information from that? I know using a kernel > compiled with -g would help, but how would that be done, because > I've been sup'ing my src every day... Yes, a kernel with -g would be a great help. The stack trace suggests a network problem, and possibly somebody with more experience in this area would recognize this signature. To build a kernel with -g, you either run config with the -g option, or better put this into the config file: makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols 'make install' will still install a stripped version, but you'll have the unstripped version to use for crash dumps. Unfortunately, you can't just build a debug kernel from these sources and expect to get the same thing; it seems that there are some minor differences in code generation when you set -g. It's possible, though, that there would be enough similarity that it would help. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: semaphores inside kernel???
[Format recovered--see http://www.lemis.com/email/email-format.html] On Monday, 18 September 2000 at 20:55:19 -0700, Mohan Krishna P wrote: > hi, It would make things a *lot* easier to read if you made your lines all the same length. I've fixed it here. > i am implementing a pseudo-devicer, many instaces of this device may > be active, all have to share a resource. all instances have to > synchronize their access to the resource. trying to implement this, > i ended up with a less powerful version of semaphores. since the > resultant code became little complex, i want to replace that with > the more generic semaphores. > > i checked the include files, but i couldn't find any semaphore > functions(semget,semctl,semop) which are specific or meant for use > inside kernel. does it mean they aren't available inside kernel?? > if i am wrong, can someone suggest me how to use them?? You're probably thinking about System V user-accessible semaphores. This particular semaphore implementation is complicated and slow, and the implementation is flawed. You don't want them in the kernel, and yes, they're not available at the moment, though you could probably do it. > does it mean they aren't available inside kernel?? if i am wrong, > can someone suggest me how to use them?? Well, the real question is, what exactly do you want to use them for? As John Baldwin says, we now have mutexes, though they won't show in a -RELEASE version for quite some time. We're still discussing the evolution of locking primitives, but at the moment it looks like we can distinguish between semaphores and "mutexes" in the following way: - A "mutex" (in quotes because "mutex" is also a generic term; this is more like a simple lock) is used for short term serialization when accessing critical data or code. Only one process can take the mutex at a time. - A semaphore may be held for longer periods of time. Multiple processes (for small values of "multiple") can take the semaphore at the same time. This means that, unlike mutexes, semaphores don't have "owners", and the process which "releases" the semaphore may not be the one that took it. Which better describes your usage? Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody know the OS in the Maxtor MAXAttach products?
On Wednesday, 27 September 2000 at 15:31:47 -0700, Jaye Mathisen wrote: > One of the comments on the side is: > > "Caching file system with Soft Update technology". > > Sounds vaguely BSD'ish. Maybe even FreeBSD'ish. > > Just curious. Maxtor have done a storage box with a modified FreeBSD, including Samba in the kernel. I don't know the name, but IIRC it's a small purple box with a couple of IDE boxes. I've heard that, for reasons that don't directly relate to FreeBSD, Maxtor isn't overly happy with the results, and that the next generation box probably won't run FreeBSD. There has even been talk that it'll be running Microsoft instead. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mtree verification output format
> >This is still very obscure; I'd like to see: > > > > size (was 1234, should be 5678) > > cksum (was 42424242, should be 69696969) > > > >...so that it's clear what the meaning of the numbers is. > > In that case I think I would like to loose the ',' also. While you're at it, why not use single word verbs: size (got 1234 wanted 5678) cksum (got 42424242 wanted 69696969) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mtree verification output format
> > > >This is still very obscure; I'd like to see: > > > > > > > > size (was 1234, should be 5678) > > > > cksum (was 42424242, should be 69696969) > > > > > > > >...so that it's clear what the meaning of the numbers is. > > > > > > In that case I think I would like to loose the ',' also. > > > > While you're at it, why not use single word verbs: > > > > size (got 1234 wanted 5678) > > cksum (got 42424242 wanted 69696969) > > Try "expected", but yes, this is a better idea. You're right, "expected" is better. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dual console with matrox g400
Wes Peters writes: > Maybe it would be possible to kludge something together using PS/2 mouse > and keyboard for one and USB mouse and keyboard for the other. This raises a question of mine: if you have a mouse that can be plugged into either USB or PS/2 ports, is one "better" than the other (under FreeBSD-4.1)? -- Greg Black <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dual console with matrox g400
On Sunday, 8 October 2000 at 10:43:34 -0600, Wes Peters wrote: > Eoin Lawless wrote: >> >> I've just got a dual head system with a matrox g400 working. However, >> what I would really like to have is a dual console system - so that >> two people could use it simultaneously. Has anyone tried that, or >> know if it is possible? > > Maybe it would be possible to kludge something together using PS/2 mouse > and keyboard for one and USB mouse and keyboard for the other. I don't > think there is anything available "out of the box" for this, though. Well, you obviously need two keyboards and two mice. I can't think of a case where that would be useful, but with x2x (in the Ports collection) you can allow different people access to the same server. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dual console with matrox g400
On Tuesday, 10 October 2000 at 0:35:07 -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Greg Lehey writes: >> Well, you obviously need two keyboards and two mice. I can't think of >> a case where that would be useful, but with x2x (in the Ports >> collection) you can allow different people access to the same server. > > In 1990 I shared a Solbourne workstation with a friend. It had two > graphics/I/O boards, which ment that you could have two independent > video consoles on it at the same time. Worked a whole lot better than > one would have expected given the relative primitive tehcnology of the > time. Glad to see that PCs are catching up :-) I had a PC with two graphics cards long before that. It was relatively common to have a machine with both CGA and MDA, and there were some debuggers which would handle both (debug a full-screen application with the debug output on the other monitor). Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: dual console with matrox g400
On Tuesday, 10 October 2000 at 0:51:50 -0600, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Greg Lehey writes: >> I had a PC with two graphics cards long before that. It was >> relatively common to have a machine with both CGA and MDA, and there >> were some debuggers which would handle both (debug a full-screen >> application with the debug output on the other monitor). > > True. But I've not seen a PC that could have multiple keyboards/mice > until USB came along. Well, I did see some kludges, but they were > fairly rare. Now, many different solutions exist that you can mix and > match... Well, multiple mice were never an issue, but the keyboard was. I had done some thinking about a serial keyboard, but mainly to get away from the stupid layouts of PC keyboards. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UDMA ICRC WRITE ERROR
On Sunday, 15 October 2000 at 13:58:15 +0200, Frank Nobis wrote: > Hi, > > I have a IDE drive spitting out this messages: > > ad3: UDMA ICRC WRITE ERROR blk# 48562489 retrying > ad3: UDMA ICRC READ ERROR blk# 24576329 retrying > ad3: UDMA ICRC WRITE ERROR blk# 69108025 retrying > ad3: UDMA ICRC WRITE ERROR blk# 73728313 retrying Is this always the same drive? >> From the boot messages: > > atapci0: port 0xd800-0xd80f at device 4.1 on pci0 > ata0: at 0x1f0 irq 14 on atapci0 > ata1: at 0x170 irq 15 on atapci0 > ad0: 8063MB [16383/16/63] at ata0-master using UDMA33 > ad1: 42934MB [87233/16/63] at ata0-slave using UDMA33 > ad2: 42934MB [87233/16/63] at ata1-master using UDMA33 > ad3: 42934MB [87233/16/63] at ata1-slave using UDMA33 > > Do I have to exchange the drive ? I think I should. You could try setting PIO mode first. > In the case of replacing is the best thing to do, that leads to the > question, how to replace this drive ? Shut the machine down. Replace drive, making sure the jumpers are set correctly. Reboot. > It is a part of a vinum raid5 volume. Is detach and attach the > right way ? No. Take a look at the description on http://www.vinumvm.org/. Sorry, I don't know the exact URL, and I'm currently off the net. One thing that occurs to me is that I suspect you're using ad[123] as your RAID-5 drive. That's seriously sub-optimal for performance, but it also means that ad2 and ad3 will frequently have transfers outstanding at the same time. That might be the real issue; you might find that if you swap ad1 and ad3 (which you can do without losing data on the volume), you will continue having problems with the new ad3. > PS. If someone want more information about the System (PRESMPNG) > dual PIII on an ASUS P2B-DS, just let me know. I want avoid spamming > the list with big config and dmesg output Right, we don't need them. Read http://www.vinumvm.org/how-to-debug.html for details regarding Vinum Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining CPU on SMP box
On Tuesday, 24 October 2000 at 7:37:12 -0400, Christopher Harrer wrote: > Hello All, > > Is there a way to determine which CPU I'm currently executing on in a SMP > box? I've found references to proc->p_oncpu, but I'm not sure if this is > the best way to determine where I'm executing. I'd like to be able to > "trace" various actions within my driver and one of the fields I want to > keep track of is what CPU I'm executing on. Which version of FreeBSD? 5-CURRENT has the ktr functions, which you could use for your tracing. They include CPU information. Unfortunately we don't have a man page yet. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Logging users out
> I wrote a little line program to do a revoke(), it was basically
>
> int main(int argc, char *argv[]) { revoke(argv[1]); }
>
> Now this doesn't kill a darn thing. And you should be aware of it! But it
> does forcibly "close" any open fd's pointing at the tty in question, and
> most programs will get the hint and go away.
Not all programs, and that can lead to all sorts of problems
with processes that never die. There are many stories of this
happening with vi, for example.
> For some uses, especially predictable uses, this is probably a lot simpler
> and a lot more foolproof.
Simple: yes. Foolproof: definitely no.
--
Greg Black <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Add a system call
On Wednesday, 1 November 2000 at 20:47:18 +0100, flag wrote: > On Tue, 31 Oct 2000, Raymond Law wrote: > >> Can someone list the steps on how to add a system call in FreeBSD 4 please? > [mega-snip] > > The response to this question seems to be great material for a FAQ. > Anybody out there would like to create it? It's also a little off-topic for questions. I'm sure you'll get better answers from -hackers, so I've replied there. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD in good standing in netcraft survey
David Preece writes: > Possibly off topic, possibly not. Am I the only one who doesn't really care > about uptimes? I certainly am not impressed by uptimes over about 100 days. They show that the site does not care about keeping current. If it made sense to have several hundred days of uptime, what is the point of all the development work done by the FreeBSD (and other OS) developers? These people work hard to improve the system and it makes sense to at least run the latest production release. In the case of FreeBSD, this means a reboot at least every three to four months when the CDs are released. -- Greg Black <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Time to close the list?
Maybe it's time to close the list so that it only accepts messages from subscribers. The spam was bad enough, but the virus warnings are over the top. Sigh. -- Greg Black <[EMAIL PROTECTED]> Join the fight against spam: http://www.cauce.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Time to close the list?
Jeroen Ruigrok van der Werven writes: > -On [20001102 09:45], Greg Black ([EMAIL PROTECTED]) wrote: > >Maybe it's time to close the list so that it only accepts > >messages from subscribers. The spam was bad enough, but the > >virus warnings are over the top. Sigh. > > I personally prefer mailing the backarsed company producing this piece > of junk. If you can get through to them, go right ahead. > I mean Precedence: bulk is a frigging standard. You know that and I know that and probably all the legitimate subscribers to the list know that -- but we're dealing with cretins here, and so we need to take effective steps against them. I don't want to unsubscribe, but I don't want all the junk either. -- Greg Black <[EMAIL PROTECTED]> Join the fight against spam: http://www.cauce.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Time to close the list?
> > 3.Automatically delete all MIME parts with: > > > > Content-Type: application/* > > > > Which are ever sent via the list software. > > What about application/pgp-signature? Indeed. -- Greg Black <[EMAIL PROTECTED]> Join the fight against spam: http://www.cauce.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
"Albert D. Cahalan" writes: > The C language is crufty. In the absense of a prototype, "short" is > promoted to "int". You wanted to be warned about that; you got it! > > To avoid the warning, avoid passing anything but "int" and "double". > Maybe "long" is OK too, I forget. I'm not sure which C language you're talking about here, but I'll assume it's C89. In that language, in the absence of a prototype, (and in K&R C), `int', `long', `double' and pointer types are not promoted; but signed or unsigned `char', `short', and `int' bit-fields are promoted; `float' is promoted. -- Greg Black <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umask(2) and -Wconversion
Giorgos Keramidas writes: > 3#define VALUE 0 > My original question was if this is not behavior that should be > considered buggy, since the size of VALUE has not been determined to be > equal to sizeof(int) when the #define occurs, or has it? The size of VALUE is not the issue; the type is `int' in the line quoted above. If you want VALUE to be a `short', you need to say: #define VALUE ((short) 0) -- Greg Black <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: post-install of kernal sources, maxusers max?
Lyndon Nerenberg writes: > FWIW I run our NFS server with NMBCLUSTERS=1. It doesn't burn that > much additional memory. As an additional data point, I had an NFS server that regularly crashed when it ran out; logs showed that it needed up to 1700 (against the default of 1024). I bumped it to 4096 about a year ago to give myself a bit of headroom and have no problems since; and I have noticed no waste of resources that mattered. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: programming: how to send signal to other program
> How can I send a signal (say, SIGUSR1) to another program with known pid? I > used to do so in Solaris using sigsend() but this call seems not available > in FreeBSD. Use kill(2), and don't send learner questions to -hackers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What about rc.shutdown.local?
Jan Grant writes: > > Better still would be /usr/local/etc/rc.d/*.sh called automatically > > with parameter stop. To do so, insert > > This is all nice (BTDT) although I find the *.sh pattern quite annoying, > due to the alphabetisation issue. When I make these mods I tend to use > the SysV-style S* and K* patterns - that means you get to control the > order of startup _and_ shutdown (which might need a different sequence). This seems trivial. I name the scripts with two-digit prefixes and an underscore so that I can have meaningful names and an easy way to control the sequence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What about rc.shutdown.local?
Jan Grant writes: > It _is_ trivial, but you miss my point: I run several things at startup > that rely on a database service (which needs to be launched first). When > they shut down, the DB must still be running (it's taken down last). So > using a *.sh pattern for startup and shutdown scripts doesn't satisfy my > requirements. It's easy to miss a pont that isn't well made. Never mind. The task is still trivial. Three obvious solutions spring to mind: 1. Put a sleep in the stop case that gives enough time for the other scripts to run. 2. Make the last script that has to run /before/ this one create a sentinel file when it finishes; let this script wait until the sentinel appears, then it removes the sentinel and does its stuff. 3. Give this script two links. On startup, it runs if it's running under the startup name; on shutdown, it runs if it's running under the other name. If none of these does the trick, they should at least point the way. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: looking for kernel hacking info
On Tuesday, 14 November 2000 at 16:32:49 -0500, Paonia Ezrine wrote: > I am looking for info on programing in kernel land. System calls, howto's > etc. I have not found anything that realy covers this stuff any and all > help would be welcomed! The system calls are described in section 2 of the manual. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: looking for kernel hacking info
Paonia Ezrine wrote: > > The system calls are described in section 2 of the manual. > thanks. do you mean handbook? No, he meant what he said. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: looking for kernel hacking info
On Tuesday, 14 November 2000 at 21:14:25 -0500, Paonia Ezrine wrote: > > >> On Tuesday, 14 November 2000 at 16:32:49 -0500, Paonia Ezrine wrote: >>> I am looking for info on programing in kernel land. System calls, howto's >>> etc. I have not found anything that realy covers this stuff any and all >>> help would be welcomed! >> >> The system calls are described in section 2 of the manual. > > thanks. do you mean handbook? No, the manual. That's the real name for the man pages. Read it with man(1). Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: looking for kernel hacking info
On Wednesday, 15 November 2000 at 10:08:45 +, visi0n wrote: > > The THC have a documentation about freebsd kernel space. > > packetstorm.securify.com/groups/thc/bsdkern.htm Repeating the full URL for the benefit of mutt users, this is http://packetstorm.securify.com/groups/thc/bsdkern.htm This is an interesting document. It describes how to insert a Trojan into the FreeBSD kernel When it came out, we discussed it and decided that it would be of no danger to a properly secured system. On the other hand, the documentation is relatively well done. We should really import it. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: any ways to look at powerpoint slides?
Julian Elischer wrote: > > I have looked in the ports xlhtml seems to extract out the text > but it's not exactly easy to see what is in the ppt slides. > > I've seen ppt presentations moved to some free S/W at usenix and BSDcon.. > how was that done? > > -- > __--_|\ Julian Elischer > / \ [EMAIL PROTECTED] > ( OZ) World tour 2000 > ---> X_.---._/ presently in: Budapest > v > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message Both Star Office & Applix can read ppt depending on the version of Power Point . -- Email: [EMAIL PROTECTED]Voice: +780 413 1910 Fax: +780 421 4929 #575 Sun Life Place * 10123 99 Street * Edmonton, AB * Canada * T5J 3H1 ---- When things can't get any worse, they simplify themselves by getting a whole lot worse then complicated. A complete and utter disaster is the simplest thing in the world; it's preventing one that's complex. (Janet Morris) begin:vcard n:Skafte;Greg tel;pager:+1 (780) 491 4791 tel;cell:+1 (780) 718 1570 tel;fax:+1 (780) 421 4929 tel;work:+1 (780) 413 1910 x-mozilla-html:FALSE org:http://www.worldgate.ca">http://dev.worldgate.ca/images/worldgate_black_200_bolder.gif">;Network Operations adr:;;#575 10123 99 Street;Edmonton;Alberta;T5J 3H1;Canada version:2.1 email;internet:[EMAIL PROTECTED] title:Operations Manager x-mozilla-cpt:;29088 fn:Greg Skafte end:vcard
Re: Printer problems, please help
[redirected to -questions; I don't consider this an in-depth technical question] On Wednesday, 29 November 2000 at 21:03:10 +0100, Rink Springer wrote: > [Posted this to questions too, but no one appeared to know.. maybe someone > here does?] > > Hi, > > I've installed FreeBSD 4.2-RELEASE on a server here (AMD K6-2 333MHz, 64MB > RAM), which does gatewaying, firewalling, NATd and finally, samba, samba for > printing. > > The box works like a charm, but printing doesn't. The printer connected to > it is an Epson Stylus Color 600, hooked to /dev/lpt0. When I print the > Windoze test page, it works (lpq happily says the file is 200KB, and it gets > printed). > > However, whenever I try to print some image that is about 1MB in the print > queue, the printer prints a small part, and the rest will not be printed. In > fact, the entire queue entry is gone! > > Does anyone know what has caused this? I noticed some stray IRQ 7's, but > even if I enable polling mode (using lptcontrol -p), it doesn't work. I need > to get this printer working soon. It worked fine using RedHat Linux 6.1. I have pretty much the same setup. Well, the CPU side is the same, but the printer's a Stylus 740. If you print documents of this size, you're probably talking about images. How do you convert the image? If you're using filters, let's see them. Also, you don't have a file size limit in /etc/printcap, do you? Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply. For more information, see http://www.lemis.com/questions.html Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sudo [was: Re: your mail]
David Talkington wrote: > sudo definitely helps if it's carefully administered, but it still > grants root access to a file, This is wrong -- sudo will grant access with whatever user privileges you wish to grant, maybe root and maybe some other user. It all depends on the way you set it up. It can also allow a selected set of users to run just one command with some specific set of arguments. It is quite a flexible tool, although that comes at a price -- somewhat difficult syntax in the config file for non-trivial tricks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GDB Displaying all vars in a stack frame.
On Friday, 8 December 2000 at 18:29:26 -0600, Stephen Hocking wrote: > Is there some simple one-liner command that allows me to display the values of > all the variables within the current stack frame? info local Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
On Tuesday, 19 December 2000 at 16:01:52 -0800, David O'Brien wrote: > On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: >> /* Case 1 */ /* Case 2 */ >> if (data) vs. free(data) >> free(data); > > > Actually from an optimization standpoint, #1 can be worse (ie, harder on > the processor). You've got a conditional jump there that is using branch > prediction HW to track (which means there is some other conditional > branch you're not, you're fetching both the taken and not take paths, > etc... If the function call isn't expensive, #2 can be "faster". In which processors is a function call anywhere near as cheap as a conditional local branch? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sitting on hands (no longer Re: FreeBSD vs Linux, Solaris, and NT)
Mark Newton wrote: > I get concerned that those who point to a lack of a QA cycle in open > source software are missing the point entirely: They're focussing on > the 'process' they're familiar with so much that they don't seem to > acknowledge that alternative approaches can demonstrate similar results. We open source zealots "know" this, but still it would nice to be able to point to some empirical data -- has anybody done a PhD thesis on it? If not, what are all the students waiting for? > At the end of the day, the track record of major open-source projects > speaks for itself: Yes, there are bugs, but there are bugs in commercial > software which is shaped and bounded by QA procedures as well. Overall, > though, I'd hazard a guess that open-source software is generally more > reliable (it is in my experience, anyway). Again, that's the common experience, but it's easier to have the experience you expect when you're not constrained by facts. I'd love to see some good statistics. After all, open source people didn't get the chance to have the Ariane-5 disaster, so our ability to point to an empty set of such examples doesn't really prove anything. I'm a True Believer in the open source / free software gospel, but it would be easier to win these arguments if only we had the data. -- Greg Black ech`echo xiun | tr nu oc | sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
On Tuesday, 26 December 2000 at 17:30:09 -0500, David E. Cross wrote: > I have run across a problem since updating to -STABLE a week or so ago... > my CVS vinum partition would go corrupt after a few updates. I have been > running with no softupdates on my system for a day now and no problems. > Has anyone else seen this? I haven't heard of any such problem, but with the details you give, it's difficult to tell. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: -STABLE+vinum+smp+softupdates+CVSup(local CVS repo)==corruption?
On Thursday, 28 December 2000 at 14:03:31 +, Josef Karthauser wrote: > On Tue, Dec 26, 2000 at 05:30:09PM -0500, David E. Cross wrote: >> I have run across a problem since updating to -STABLE a week or so ago... >> my CVS vinum partition would go corrupt after a few updates. I have been >> running with no softupdates on my system for a day now and no problems. >> Has anyone else seen this? > > Is that with vinum raid 5? If so there are know problems with raid 5 > and you should either help Greg to fix them or avoid raid 5 like the > plague lest your data corrupts itself. I can't recall any data corruption. The problems you were seeing were panics where buffer headers got corrupted, and they happened to a very small number of people (not including myself, which makes it difficult to catch them). I think I might have a solution there. It's currently being tested in -CURRENT, but before that I'd like to find somebody who can reproduce the original problem. I certainly don't think it's a reason to avoid RAID-5, like the plague or otherwise. You'll notice that David's problem has nothing to do with that, nor with Vinum at all, it would seem: On Thursday, 28 December 2000 at 11:52:03 -0500, David E. Cross wrote: > No, I am just using vinum stripes. The problem seems to have fixed itself > when I got a ufs_readwrite.c update from Matt after it was committed. > > This is an interesting problem, since I am not entirely sure what > fixed it, if it is really fixed, etc... Indeed. Was this just the CVS repo? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel debugging suggestion needed
On Tuesday, 2 January 2001 at 14:03:16 -0800, Doug White wrote:
> On Tue, 2 Jan 2001, Zhiui Zhang wrote:
>
>>
>> I have written a KLD and am debugging it. The program often hangs after
>> runs for a while (I guess it enters into some dead loop). Is there a way
>> to attach to the process and somehow find out which code it is executing
>> (with remote debugging or ddb)?
>
> kld debugging is a bit tricky. Take a look at the debugging macros and
> bits that Greg Lehey put together for vinum for a starting point. You have
> to calculate the appropriate offset to get to the KLD code in gdb.
Doug Rabson has described an alternative to me, but I never got it to
work. My hack walks down the list of klds looking for a name starting
with 'v'; you can change this to something which identifies your kld,
and you'll need to change the name of the kld itself, of course. I
also have a number of other macros in files in
/usr/src/sys/modules/vinum.
Here's the macro:
define asf
set $file = linker_files.tqh_first
set $found = 0
while ($found == 0)
if (*$file->filename == 'v')
set $found = 1
else
set $file = $file->link.tqe_next
end
end
shell /usr/bin/objdump --section-headers sys/modules/vinum/vinum.ko | grep ' .text'
| awk '{print "add-symbol-file sys/modules/vinum/vinum.ko \$file->address+0x" $4}' >
.asf
source .asf
end
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel debugging suggestion needed
On Tuesday, 2 January 2001 at 23:22:49 -0500, Zhiui Zhang wrote: > On Tue, 2 Jan 2001, Doug White wrote: > >> On Tue, 2 Jan 2001, Zhiui Zhang wrote: >> >>> >>> I have written a KLD and am debugging it. The program often hangs after >>> runs for a while (I guess it enters into some dead loop). Is there a way >>> to attach to the process and somehow find out which code it is executing >>> (with remote debugging or ddb)? >> >> kld debugging is a bit tricky. Take a look at the debugging macros and >> bits that Greg Lehey put together for vinum for a starting point. You have >> to calculate the appropriate offset to get to the KLD code in gdb. > > I already did this. I hope that I can find a way to know which process is > running which part of the KLD code endlessly. There are other macros in my .gdbinits which give you backtraces of other processes. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > Is there anyone out there who feels like rejecting the proposal > for a *reason*? Or to accept the idea, but to redirect the > effort to a "real solution"? I somehow doubt you'd rather > explain again and again that cron(8) isn't broken but that users > should shuffle around the daily job's execution time ... I'm opposed to the changes. Those people who live in places that use daylight savings time should be aware of its effect on their lives and should understand that scheduling events to fall during the missed or repeated time at the changeover (whether by cron or by any other mechanism) is going to produce anomalous results. Therefore, the /right/ thing to do is to avoid the times where this problem can occur. IMO, the solution is to put a note at the top of the distributed /etc/crontab file suggesting that people who have DST not put jobs in the transition times, together with similar notes in the relevant man pages and in comments at the top of the files that are generated by crontab. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: debugging kernel buffer overwrite
[following up to -hackers]
On Tuesday, 2 January 2001 at 14:35:39 -0500, Jeff Fellin wrote:
>
> I previous sent this mail on freebsd-current, but realize it
> was probably an incorrect list. So, I am reposting on to
> freebsd-questions. If this is still the wrong list could
> someone tell me the best list to post this question to?
FreeBSD-hackers, probably. -questions is for administrative rather
than programming issues.
> I am having a problem with a device driver that uses physio
> to transfer data to a SCSI adapter. Some times the after
> passing the buffer to the CAM system, via xpt_action, the
> buffer contents are modified. I've traced my driver and cannot
> determine how this could be happening. I am running on a single
> CPU Pentium II system with all system config defaults.
>
> What I would like to do is to dynamically set a watch point
> on the buffer used by the write system call for the duration
> of sending the data to the SCSI adapter. I want to do this
> dynamically instead of manually setting a breakpoint in the
> code and manually setting the watch point, because the problem
> occurs around the 90'th time, and I don't want SCSI bus timeouts
> while typing the watch address.
>
> I've examined the ddb code, and thought that if I emulated the
> steps in db_trap() for the command of setting a watchpoint it
> would work. However, it doesn't appear to be working.
>
> What I've done is:
>
> /* possible on data xfer >= 512 bytes */
> if (condition for problem) {
>
> db_watchpoint_cmd(bp->bio_addr, bp->bio_addr,
> bp->bio_count, &"rw");
Why &"rw"? The parameter is a char *, which is the type of "rw".
> db_continue_cmd(0, 0, 0, &"w"):
> db_restart_at_pc(FALSE);
> }
>
> When the buffer is done transmitting I do the following:
>
> db_clear_watchpoints();
> db_deletewatch_cmd(bp->bio_addr, bp->cio_addr,
> bp->cio_count, &"rw");
> db_continue_cmd(0, 0, 0, &"w");
> db_restart_at_pc(FALSE);
>
> My driver trace printf's show the data at bp->bio_addr was
> changed from 0x601000a3 to 0x0.
That's a strange initial address. I didn't think we had anything
mapped at 0x601000a3.
> Additional traces show the data from the first 200+ bytes is changed
> to zero.
In the buffer header, or in the data buffer?
> Any guidance on how to use the ddb functions to debug this problem
> are appreciated. Also, alternative methods to determine what is
> overwriting the buffer. In looking at the data on a SCSI bus
> analyzer, the entire buffer has been zero'ed out.
Hmm. You don't say what goes wrong, nor whether your breakpoints ever
get set. In the past I've used the debug registers for this, which
has the advantage that, if you know where it's going to get broken,
you can set a memory access breakpoint and catch it in the act. I can
drag out the functions if you like.
Greg
--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply.
For more information, see http://www.lemis.com/questions.html
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
psmintr: out of sync
I have an intermittent (and fairly rare) problem with various
PS/2 mice on a set of boxes running 4.1-R (but the problem was
also evident under 3.{1,2,3,4}-R). The boxes all run X and, on
occasion, the mouse will stop working and hundreds of "psmintr:
out of sync" messages will be logged.
It happens maybe once in 6 weeks on one of seven machines, so is
not easy to diagnose.
I can fix it by logging in with ssh (or switching to one of the
virtual consoles if the box is handy), killing and re-starting
moused.
This is not a very useful solution for distant clients who are
not competent to do stuff like that and tend to resort to the
power switch if I'm not available instantly -- and that leads to
undesirable collateral damage.
I'm keen to hear practical suggestions for a fix, or even better
that a bug has been found and fixed.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: StrongARM support? (was also: Group for porting to other proccessor families)
On Monday, 8 January 2001 at 0:22:01 +0800, Kathy Quinlan wrote: > Hi all > > Is their a group of FreeBSD Enthusiasts that are working on porting > free to embedded controllers that are not x86 I am in the process of > developing a security / access / building management system, and am > looking at using free on all my outlying units. I am not interested > in using pc104 etc but using processors like the atmel thumb > processor, this is a risc based uC capable of handling 64Mb of flash > ram for program and working ram. why do I want an OS for an > industrial app, simple some units may be standalone and need > dialling into, building units will probably be TCP/IP. If I understand correctly, this is an ARM architecture. Almost the same time you wrote that, this message was sent to -hackers: On Sunday, 7 January 2001 at 6:20:26 -0800, Jordan Hubbard wrote: > [missing attribution to Michael C. Wu] >> I'm definitely interested in both StrongARM and PPC. (and so are very >> many people) My understanding is that FreeBSD *wants* a FreeBSD/ARM, >> but lack the resources/man-power to do so. I'd prefer to see an >> official decision on the above by someone (hint hint -core :)) though. > > I don't think any "official decision" would say anything we in core > haven't already said individually and many times over the years. > Sure, FreeBSD wants ARM and PPC ports but currently lacks, at least to > our knowledge, the man-power to lead and support such a project. You > said it yourself. If some motivated individuals out there would > like to change that situation, you have our full support! Porting to ARM isn't going to be trivial, but the obvious first step is to get interested people together. Note that we've had a SPARC porting effort languishing out there for years now. If ARM is to do better, it will need significant support. Jordan's response above was made without his -core hat on. If people want a response from -core (which I suspect will probably be very similar), they should send mail to -core asking for it. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Dump analysis (was: Ideas? (fwd))
On Monday, 8 January 2001 at 10:04:44 +0200, Roman Shterenzon wrote: > * Roman Shterenzon <[EMAIL PROTECTED]> [010107 10:24] wrote: >> Hi, >> >> Could you please take a look at : >> http://www.freebsd.org/cgi/query-pr.cgi?pr=24019 >> It's my friend's PR. Can you give me some hints on how can I debug this >> issue. I'm completely puzzled here. >> It panics on "goto out" with page fault. What I understand from it is that >> the block at the address it tries to jmp to isn't present. But it's kernel >> code which is never swapped out. Does it mean that the address was >> rewritten? If it's so, what can rewrite this address? Ideas? My first suspicion here is that the sources are out of sync with the kernel you're debugging. It's very important to ensure that they are absolutely in sync. Here are a couple of incantations to throw at this dump (you may recognize the second one from an earlier mail exchange): (kgdb) x/10i epread (kgdb) x/10i 0xc012a038 The first one should show the beginning of the function; if it's in sync it will look like (modulo addresses): (kgdb) x/10i epread 0xc0165f8c :push %ebp 0xc0165f8d : mov%esp,%ebp 0xc0165f8f : sub$0x1c,%esp 0xc0165f92 : push %edi 0xc0165f93 : push %esi 0xc0165f94 : push %ebx 0xc0165f95 : mov0x8(%ebp),%eax 0xc0165f98 : mov%eax,0xfff4(%ebp) 0xc0165f9b : mov0x118(%eax),%edx 0xc0165fa1 : add$0x8,%edx In particular, those first two instructions are at the beginning of just about every function, so if you don't find them, you should check whether your code is in sync. >> P.S. Can it be due to faulty hardware? Or faulty Italian cuisine? In each case, not if it's repeatable. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Doug Barton wrote: > Neil Blakey-Milner wrote: > > > > On Tue 2001-01-09 (02:14), Doug Barton wrote: > > > Gerhard Sittig wrote: > > > This way, we never repeat jobs, and never lose jobs. Which makes cron > > reliable. > > For your definition of "reliable." Personally, I find cron doing exactly > what it's told and not trying to think for itself "reliable." Indeed. > > And when you finally realize that everyone else thinks this is a great > > idea, > > In fact, I'm quite sure that this is not true. I happen to be the only one > who is currently voicing opposition. No, you're not the only one opposed. I've stated my opposition previously and will re-state it here. If any change to expected cron behaviour is to be introduced, the traditional behaviour must be the default, with a knob documented in the man pages that can be twisted to get the oddball behaviour that is being proposed here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Neil Blakey-Milner wrote:
> On Wed 2001-01-10 (21:20), Dan Langille wrote:
> >
> > IMHO, the solution is not to schedule jobs during during the changeover
> > period. However, *if* the mods are adopted, it should default to off. Add
> > a switch to turn them on. See how that runs for a few years. Then, and
> > only then, if the feedback is positive, consider changing it to the default
> > behaviour. Such a radical change to cron cannot be implemented
> > without sufficient field testing. That will take years. It cannot be
> > simulated.
>
> These changes have been tested in OpenBSD for 3 years.
That's not the same as testing under FreeBSD. And it's not just
a matter of testing anyway -- it's a matter of changing well
known and understood behaviour that has been in place for
decades for no other reason than that some people seem to be
unable to understand simple facts, such as the fact that playing
arbitrarily with clocks for DST leads inevitably to certain
anomalies in all kinds of scheduling.
Solutions to this include running the scheduler under a more
sensible time regime, such as UTC or TAI -- always an option for
cron, or avoiding the scheduling of tasks for times that can
either occur twice or not at all -- usually an option for Unix
cron tasks. None of this is rocket science.
Fiddling with cron to work around incompetent sysadmins just
exposes the rest of us to new bugs in cron -- a program that we
depend on for a large range of important tasks.
Of course, those of us who don't want to be bitten by the weird
new behaviour will have the option of retaining the current
(rather unattractive) BSD (aka Vixie) cron or of replacing it
with an entirely new tool and disabling the supplied cron
altogether, in much the same way as many people remove sendmail
in favour of qmail or named in favour of djbdns.
> The "solution"
> is _not_ to tell people they're stupid to schedule jobs during the
> changeover.
It's not a matter of telling people "they're stupid to schedule
jobs during the changeover," it's a matter of expecting them to
understand what it means to do that in those benighted places
that resort to DST.
> However, since it _does_ have this "feature", we should
> accomodate people who are negatively affected by it.
I think we should accommodate them in exactly the same way we
accommodate people who are negatively affected by the lack of
support for Word documents in vi, surely a far more pressing
problem.
> It _will_ fix the
> twice-yearly complaint about extra and missing jobs.
And that will reduce the list traffic of that type by a truly
insignificant amount.
> It may create
> unexpected behaviour for a tiny percentage. Those people should be
> reading the release notes ("or they shouldn't be system administrators
> or run FreeBSD").
Those people do read the release notes, just as they read the
stuff that gets on this list -- and at least some of them have
expressed strong reservations about the proposed changes. It
seems clear that the loudest noise comes from the proponents, so
I guess I'll have to dust off the sources to my old personal
cron implementation in readiness for the day when this thing
gets into the distribution.
> Again, this change is from OpenBSD. We will synchronise with their
> changes, and perhaps offer them back a patch to ignore what "ultra leet
> sysadmins who rely on broken behaviour because people who don't are
> simply stupid and shouldn't be running FreeBSD anyway!" with an option.
I cannot parse the final sentence above and don't think it adds
much to the case that is being made here. Since it seems that
heat rather than light is the base of much of the discussion, I
think I'll drop it now -- apart from a final plea that the new
behaviour be made to default to off if it gets up enough support
to be incorporated into FreeBSD.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Neil Blakey-Milner wrote: > On Wed 2001-01-10 (21:35), Greg Black wrote: > > To summarise: It is broken, we have the fix, No. You believe it is broken; you believe you have a fix. Not everybody agrees that it is broken or that any fix is required. > > Fiddling with cron to work around incompetent sysadmins just > > exposes the rest of us to new bugs in cron -- a program that we > > depend on for a large range of important tasks. > > Here you are doing it again. You're calling people who expect a tool to > work in a reliable and obvious way "incompetent", No, I'm calling people who can't be bothered finding out how things work incompetent. > If you hadn't noticed > (despite my indication of the fact), I was attempting to emulate the > style of the detraction; that's why you seem to believe I'm getting > worked up over this. Trust me, I'm not. You appear to be worked up, and denials don't reduce that appearance. > What we haven't seen is any technical opposition to the algorithm used, > which has been explained. If there is a problem with it, then that > should be determined. My review of it indicates the OpenBSD cron > behaviour is very specific, reliable, and obvious. People who don't believe in the justification for the change are not going to waste their time reviewing the implementation. If that's going to be done, it will have to be done by somebody who thinks the idea makes sense. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > I take notice of your (and Greg Black's) reservation / being > opposed, respect it and conclude that the change will have to > - default to the current behaviour (something quite usual for > expanding changes) We'd need some guarantees that the attempt to maintain current behaviour was done correctly -- i.e., without introducing bugs that broke things. > - be well documented (something absolutely clear to all of us, > strictly speaking it's way out of imagination for us how > somebody could contribute undocumented stuff ... :) One of the things that would need to be documented is what will happen to the new algorithm in the situation where cron is stopped and re-started during one of the time periods that gets repeated. > - yet be enabled easily for those interested in the change to > work for them and free up some of their resources for more > important tasks > - maybe provide knobs (besides the on-off-switch) to customize > behaviour in a more fine grained way In the beginning, something like CRON_DST_HACK="NO" in rc.conf with a comment pointing to the explanation should cover both these items. If more is needed later, then it can be added. > BTW: There's good news for those with a dislike regarding the > change: While testing I'm stuck again, so there will be some > more delay. Previously we were told that this stuff had already been tested for years under another OS and was therefore robust and reliable. Now we learn that these claims are not correct. And you wonder why people are reluctant to even consider these changes ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
"Dan Langille" wrote: > On 11 Jan 2001, at 16:33, Greg Black wrote: > > > We'd need some guarantees that the attempt to maintain current > > behaviour was done correctly -- i.e., without introducing bugs > > that broke things. > > What sort of guarantees are acceptable? It would need to be tested against a set of "suitable" test crontab files across both ends of DST transitions using real timezone files -- either by running it for several months in -current or by dedicating a test machine that was rebooted several times for date changes a few days before and after the DST transitions. Faking timezone files leads to suspicions about bugs in them. Changing the date on a running system without rebooting leads to uncertainty about side-effects of large date changes. If I was doing this, I'd be looking for input with test data for the crontab files and I'd be looking hard (in advance) at the kinds of outcomes that would serve to validate the behaviour. Having once written and then maintained a cron implementation (more than 10 years ago), I do know that covering all bases is non-trivial. And, as I said previously, I'd want to know how the new code coped with cron being stopped and restarted during one of the DST transition times, as well as seeing assurances that the legacy version would do the same thing then as it does now. > > In the beginning, something like CRON_DST_HACK="NO" in rc.conf > > with a comment pointing to the explanation should cover both > > these items. If more is needed later, then it can be added. > > Do you mean /etc/defaults/rc.conf? One of the ways we break the POLA is the habit of changing the names and locations of those files. But yes -- if that's still its name when/if this thing happens. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > On Thu, Jan 11, 2001 at 16:33 +1000, Greg Black wrote: > > > BTW: There's good news for those with a dislike regarding > > > the change: While testing I'm stuck again, so there will be > > > some more delay. > > > > Previously we were told that this stuff had already been tested > > for years under another OS and was therefore robust and > > reliable. Now we learn that these claims are not correct. And > > you wonder why people are reluctant to even consider these > > changes ... > > "We were told UNIX had been around for some thirty years, is said > to be functional / reliable / flexible / add whatever you use and > love UNIX for. And now we learn it doesn't even work easily for > those simple tasks as networking / printing / gaming / etc are?" > > Excuse me, please? Could it be that you got more from my > messages than what I actually said? Please read more carefully. I said: "we were told that this stuff had already been tested for years [...]". I did not say who made this claim, although I assumed that those few people who are following this thread would have remembered who it was. The claim /was/ made. I suggested that it was invalid. I still think that. As for the implementation issues that you covered in detail, I have no comment as I'm not interested in reviewing the code for a change that I see no case for. > I understand that having the clock jump is a Bad Idea(TM). > Especially when it is jumping backward since this violates the > model we have of time (*always* monotonously increasing [...] It may be monotonous, but it's supposed to be monotonically increasing. > And I realize that the DST topic is anything but trivial, cannot > be handled by my ported patch and actions can easily do harm when > done incorrectly. The only solutions turn out to be > - education [...] Not such a bad method. We use it for all the "How do I remove a file named -x?" questions -- we don't "fix" rm or the way the shells parse commands. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Daemon images (was: One thing linux does better than FreeBSD...)
On Monday, 15 January 2001 at 13:40:38 +0100, Poul-Henning Kamp wrote: > > There is one point where I have to conceed defeat to Linux. > > That fat little penguin is everywhere. > > The main reason we practically don't see beastie at all is that > there is no artwork to get hold of anywhere... > > Please, somebody, anybody: Can we have some beastie artwork in > usable sizes for posters, T-shirts and such ??? And images which will fit on business cards, please. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Daemon images (was: One thing linux does better than FreeBSD...)
On Monday, 15 January 2001 at 8:41:51 -0800, Richard Hodges wrote: > On Mon, 15 Jan 2001, Poul-Henning Kamp wrote: > >> There is one point where I have to conceed defeat to Linux. >> >> That fat little penguin is everywhere. >> >> The main reason we practically don't see beastie at all is that >> there is no artwork to get hold of anywhere... >> >> Please, somebody, anybody: Can we have some beastie artwork in >> usable sizes for posters, T-shirts and such ??? > > I'm not an artist, but I can visualize a graphic that I think > would be pretty cool... > > Picture the Daemon standing next to a penguin. > The penguin is holding a flag, as if a colorguard. > Make that a MS flag. > And the Daemon is setting it on fire... That's not the impression I'd like to make. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Daemon images (was: One thing linux does better than FreeBSD
On Monday, 15 January 2001 at 16:00:55 -0800, John Baldwin wrote: > > On 15-Jan-01 Greg Lehey wrote: >> On Monday, 15 January 2001 at 13:40:38 +0100, Poul-Henning Kamp wrote: >>> >>> There is one point where I have to conceed defeat to Linux. >>> >>> That fat little penguin is everywhere. >>> >>> The main reason we practically don't see beastie at all is that >>> there is no artwork to get hold of anywhere... >>> >>> Please, somebody, anybody: Can we have some beastie artwork in >>> usable sizes for posters, T-shirts and such ??? >> >> And images which will fit on business cards, please. >> >> Greg > > The little beastie in the BSDi logo fits rather nicely on my business card... URL? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote:
> On Wed, Jan 10, 2001 at 08:51 +1000, Greg Black wrote:
> >
> > If any change to expected cron behaviour is to be introduced,
> > the traditional behaviour must be the default, with a knob
> > documented in the man pages that can be twisted to get the
> > oddball behaviour that is being proposed here.
>
> In http://www.freebsd.org/cgi/query-pr.cgi?pr=24358 ("/etc/rc
> variables for cron(8)") I suggest how to provide knobs to pass
> parameters to cron as well as to switch to a different cron
> executable, while of course leaving current behaviour as the
> default.
This looks fine to me, as far as it goes. I'm assuming here
that the proposed new behaviour for cron will only be enabled if
a specific flag is provided?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
Michael Bacarella wrote: > Why is crontab suid root? It has to run jobs as the correct user and must be able to setuid accordingly. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Permissions on crontab..
Dan Nelson wrote: > In the last episode (Jan 17), Greg Black said: > > Michael Bacarella wrote: > > > Why is crontab suid root? > > > > > > I say to myself "To update /var/cron/tabs/ and to signal cron". > > > > > > Could crontab run suid 'cron'? > > > > > > If those are the only two things it needs to do, run cron as gid > > > 'cron' and make /var/cron/tabs/ group writable by 'cron'. > > > > It has to run jobs as the correct user and must be able to setuid > > accordingly. > > Not quite. As far as I can tell, crontab is setuid root for the sole > purpose of being able to write to /var/cron/tabs. Cron checks the > timestamp on the directory every minute, so crontab doesn't have to > signal it for changes to get noticed. Previously, I wrote a bit faster than is good. There are indeed cron implementations where crontab signals cron, and they must be setuid root. However, as noted above, that's not the case with the current FreeBSD implementation. > If you're paranoid, you can > probably "chgrp cron /var/cron/tabs" and make crontab setgid cron > without any ill effects. Cron itself must stay setuid root, of course, > so it can run user crontabs as that user. At least I was not the only person to write hastily. It is not normal for cron to be setuid (and it is not on any BSD machine that I can check right now). It must be run by root, but that is accomplished by starting it from /etc/rc at boot time (or by root re-starting it as needed during normal operation). Dropping the setuid bit on crontab in favour of a setgid cron alternative also means changing the permissions on the /var/cron/tabs directory which is currently only accessible to root. I'm not sure I would want anybody else to have access there. But it would probably work OK. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Gerhard Sittig wrote: > I'm just editing the PR with the cron patches to "catch up" with > OpenBSD in this respect (stating that it doesn't handle DST, but > has benefits whenever one's clock is jumping or cron waking up > too late and _could_ be extended to handle DST). Therein I > suggest to > - not touch current cron at all but switch to a different > executable by means of the newly introduced rc.conf variables > or to > - modify cron but make the new code optional while defaulting to > off I prefer option 1. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to fix "make buildkernel requires full obj directory" mistake
Dan Langille wrote: > On 18 Jan 2001, at 20:13, Warner Losh wrote: > > > Still, I don't think it is too onerous a requirement that a buildworld > > have happened first. > > I disagree. Unless you qualify the above, you're saying that if I install > FreeBSD for the first time, in order to create a custom kernel, I need to > make world. Sorry, but that's breaking a long standing tradition of not > needing to make world before building a customer kernel. And > expecting someone new to FreeBSD to master build world before > getting them used to building a kernel is a bit too much of an ask. I haven't been following this thread, so I may have missed something here, but the comment above rang some alarms. Does any of this affect people who simply install a RELEASE from CD and then build a kernel to get their config the way they want? I'm assuming it doesn't, but I got worried by what you said here. Like lots of people who use FreeBSD rather than tinker with it, I have never done "make any-kind-of-world" and never expect to. I create a kernel config with my stuff in it, and do config, make, make install. I trust this is not going to be broken? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
Sergey Babkin wrote: > Neil Blakey-Milner wrote: > > > > On Sat 2001-01-20 (16:39), Sergey Babkin wrote: > > > All, > > > > > > I've committed these changes for cron to support DST change > > > to -current (see PR bin/24494 for description of my tests). > > > Everyone is welcome to test them out. > > > Please let me know if you encounter any problems caused by them > > > (and better do that before these changes would be MFCed to -stable > > > in a few weeks). > > > > I do believe this is premature. There really should at least be an > > option for the old behaviour, and there is a good argument for making > > the new behaviour optional dependent on a variable with the old > > Let me ask a simple question: Why ? What are the benefits of > preserving the old behavior ? As far as I've watched this thread > nobody had explained it. So could you please elaborate ? You have not been paying attention. Please go back and /read/ the archives on this topic which has been thrashed out in great detail here. We did not reach agreement about the desired behaviour because the nature of this issue is that different people desire different behaviour. What was agreed by those who contributed was clearly that the old behaviour was to be preserved by default and that new behaviour was to be enabled by a command-line option, which could be set in rc.conf. You have shown no reason not to go with the solution that was agreed, so please don't just jump in with your big boots on insisting that you know best. Nobody knows best about this. > > behaviour default. _Especially_ if you intend to MFC this, since > > changing this behaviour in a minor release, without a way to have the > > old behaviour, is almost certainly wrong. > > That's why I asked for comments. You should have read the thread more carefully. But you have been given comments now. Take heed of them and don't push ahead with this plan. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [MAILER-DAEMON: Returned mail: see transcript for details]
Jamie Heckford wrote: > Sorry if this is the wrong place to post this, but > I think it needs attention. It is the wrong place and the only attention it needs is from you. Read the message and understand it -- that should not be too hard for somebody who claims to be: > Chief Network Engineer > Psi-Domain - Innovative Linux Solutions. Ask Us How. Hint: use the same method of posting to the gnats address as you used to post this question -- via your friendly ISP, not direct from a dialup. Any further questions can be answered by reading the information at http://mail-abuse.org/dul/ or, if it's really necessary, by asking on the questions list. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etccrontab)
Sergey Babkin wrote: > It still can be backed out. Well, what are you waiting for? Back it out. Listen to what people are saying and then maybe propose something that takes into account their concerns. To make this point a little more clearly -- the fact that Matt Dillon, who is no fool, and you have wildly divergent ideas on the appropriate/correct method to determine when to do things is further evidence (as if any were needed) that this is not a trivial thing to get right. First, people have to agree on what is right and we're not there yet. Please take note of what people are saying, stop the silly protests about your failure to be convinced by other people's arguments, and recognise that you don't have a special line to the One True Way. Finally, in reference to the confusion over POLA, get something straight: the people we must take most care not to astonish are current users of FreeBSD; after them, we can consider users who are migrating from other Unix variants. The fact that others may do things differently is not, of itself, an argument to take a wild jump into the darkness here. The continued, predictable, behaviour of cron is important to users and cannot be just played about with at your whim, and this is especially true when you don't even have support for the so-called solution you have proposed. Back it out. Do it now. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dramatic cron changes are premature Was: Re: cvs commit: src/usr.sbin/cron/cron cron.8 cron.c cron.h
Sergey Babkin wrote: > To mention it from the start, I've backed out my changes. Thank you. > There are other things which may not allow a job to finish in > a predefined time slot. For example, other operations going on > and consuming CPU, disk or network bandwidth. So presuming > that a job would finish by some time is inherently unsafe. > The safe way is to put both jobs sequentially into one script > and run this one script from cron. Remember that for later. > Time critical jobs should be avoided at all, by including all the > dependent jobs into one script and running only this script > from cron. And remember that while you read this: > I can give you one example from my past experience: a nightly cold > backup of a database which takes a long time, must be started after > all the day's work would be complete, and finish by 7:30AM the next > morning. The time of backup depends on the amount of change logs > generated during the day, so to be safe it should be started as > early as possible. Well, eventually we got the day's close > processing to complete by 12:50 and scheduled the job there. > But the fact that two hours of time are unusable for starting > any jobs is not a particularly exciting one nor fun to discover. This is an absurd claim, especially in the light of what you said earlier (quoted above). If the backup depends on the processing of something else, then the script that starts the other processing should run the backup at the end, and issues of DST are completely irrelevant. This has always been the case, and still is. You keep demanding technical arguments (which I think means arguments about the content of the proposed changes) -- but the matter of concern to me is /not/ that at all, it's whether there is any need for potentially breaking an important utility which has known behaviour to "solve" things that don't need and are not suited to technical solutions, no matter who else might think that is the way to go. Arguing that commercial Unix vendors have decided to meet the lowest common denominator by changing cron is not a case for FreeBSD to go down the same road. > > > > I made the additional point that the options should be command line > > > > options, instead of environment variables as someone else suggested. > > > > > > And I made the additional point that practically all the commercial > > > Unixes do support intelligent handling of DST. Being different > > > from them makes no good and is a lot of inconvenience. > > > > If you want to offer the option of making cron think for the user > > instead of following traditional behavior then it should be offered as a > > command line option, defaulting to off. Period. "We're not like everyone > > else" is not a compelling argument here. > > This sort of arguments is largely responsible for why Unix had > branched in so many incompatible ways. The NIH syndrome is not > the most productive approach. A certain TLA once came out with their own Unix (known by another TLA) and I had the joy of working with beta versions of this OS. Thousands of things just didn't work, including dozens of awk scripts. It turned out that the company had "audited" the awk code and "fixed" it to comply with their in-house coding standards. Just because other people do something is not of itself a compelling argument to follow suit. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info
On Wednesday, 24 January 2001 at 17:08:16 -0500, Dennis wrote: > >> >>>I'll look into the Linux driver, however, and see if it has anything >>> useful in it. Historically the Linux Pro/100+ driver has totally sucked and >>> was chalk-full of magic numbers being anded and ored. >> >> That's "chock full", and you're confusing the Becker driver (bad) with >> the Intel-supplied driver (slightly less bad). > > The intel driver seems to cover all the bases and has some nice glue > routines for determining the part and features available. We recently did some testing of these drivers at my company. We found both drivers to be very bad, and the consensus was that the Intel driver was worse. We were not able to keep a link up under load for more than a few hours. > I havent tested it under load, but I wonder if intel would consider > supporting it if someone ported it over to freebsd? they have drivers for > just about every other major OS except BSD. it would be nice if the driver > was updated BEFORE cards and MBs that dont work started showing up on the > loading dock. Every time I get a shipment we have to hold our breath until > we try one out. I've come in in the middle of this discussion, so maybe there's something I don't know, but on the same hardware and running FreeBSD, I had no problems. Why should we want to replace the driver with something which doesn't work well? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info
On Wednesday, 24 January 2001 at 21:07:45 -0800, Matt Jacob wrote: >> >> I've come in in the middle of this discussion, so maybe there's >> something I don't know, but on the same hardware and running FreeBSD, >> I had no problems. Why should we want to replace the driver with >> something which doesn't work well? > > There's been a hint of 'vendor supported' We saw no evidence of that. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info
On Thursday, 25 January 2001 at 12:54:17 -0600, Jonathan Lemon wrote: > On Thu, Jan 25, 2001 at 01:12:42PM -0500, Dennis wrote: >> At 10:58 PM 01/24/2001, Jonathan Lemon wrote: >>> In article >>> [EMAIL PROTECTED]> >>> you write: >>>> >>>>> >>>>>>I'll look into the Linux driver, however, and see if it has anything >>>>>> useful in it. Historically the Linux Pro/100+ driver has totally >>> sucked and >>>>>> was chalk-full of magic numbers being anded and ored. >>>>> >>>>> That's "chock full", and you're confusing the Becker driver (bad) with >>>>> the Intel-supplied driver (slightly less bad). >>>> >>>> >>>> The intel driver seems to cover all the bases and has some nice glue >>>> routines for determining the part and features available. >>>> >>>> I havent tested it under load, but I wonder if intel would consider >>>> supporting it if someone ported it over to freebsd? they have drivers for >>>> just about every other major OS except BSD. it would be nice if the driver >>>> was updated BEFORE cards and MBs that dont work started showing up on the >>>> loading dock. Every time I get a shipment we have to hold our breath until >>>> we try one out. >>> >>> The documentation is available, if you want to (or have to) sign an >>> NDA. People who have the NDA documentation are perfectly capable of >>> writing a driver, although the source can't be released. It would >>> probably be possible to release a binary driver, but why do anything >>> to help Intel, given their unhelpful attitude? >> >> If they have a published, freely distributable driver for linux. why would >> you have to sign an NDA to port it to FreeBSD? >> >> I dont think so. Not anymore anyway. Thats the whole point of this thread... > > Having looked at the Linux driver, the FreeBSD driver, and the > documentation, I can tell you that assuredly not all of the features > are documented in the Linux driver. Also, porting requires changing > things, and without an understanding of _WHY_ things are done the > way they are, you can end up invaderdently changing something that > turns out to be critical. > > Also, the Intel driver isn't put together very well, so you might end > up with a lower performance driver after all is said and done. Performance isn't even the main thing. As I said earlier, it's plain bloody unreliable. Linux people avoid the EtherExpress because they think something is wrong with the card. They were surprised when I reported that it works without any problems under FreeBSD. Do we really want to change that? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel Hacking (i tried not to make it lame)
On Thursday, 25 January 2001 at 22:03:35 -0500, [EMAIL PROTECTED] wrote: > hey guys i know you probably get this question all the time but i am looking > into getting into doing somekernel hacking first i will tell you some thing i > have assumed about it: > 1.) you should know atleast more programming language well (probably C would > be best) > > 2.) you should know some basic stuff about FreeBSD internels (i am planning > on getting The Design and Implementation of the 4.4BSD Operating System Correct on both counts. > that is about it the rest really is a blur and is so complex and > huge i have no idea where to begin hope i wasn't to lame guys :-) Well, once you have the book, look at something you might find interesting, and play around with it a bit. If you keep a "diary of a learning hacker" on the web, you might do a great favour to a number of people like yourself. If you run into trouble, ask here. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp driver info (which card then?)
On Friday, 26 January 2001 at 9:47:38 -0500, Jim Sander wrote: >>> Linux people avoid the EtherExpress because they think something is >>> wrong with the card. > >> Intel EtherExpress Pro 10/100B cards in FreeBSD > >These cards work well in our many 3.x and 4.x systems. > >But I just built up a Redhat 6.2 box with one, and all seemed to be > working fine, but after a while I started having various problems starting > net services. The box would boot, but often would "hang" indefinitely when > "Starting eth0" - requiring a hard reboot. I swapped to another EE-Pro > NIC, new MB, different RAM, other cables, everything, but no change. Yes, these are exactly the problems I've heard of. >After I switched to a linksys NIC, voila- everything worked > without a problem. (so far) Of course the Intel NICs still work > perfectly when put into a spare BSD system. So it's *not* that the > cards themselves are unreliable. Perhaps the drivers controlling > them? Perhaps a weird MB/NIC conflict of some sort? As I mentioned earlier, it's the drivers (two different ones) themselves. Linux people have different opinions about which is worse, but they do agree that both are pretty bad. That's why I've been saying that we shouldn't be looking at porting them. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Chuck Cranor's PhD thesis on VM
On Sunday, 28 January 2001 at 21:10:34 -0700, Ronald G Minnich wrote: > I am sorry I brought this up without a URL :-( > > I'm working on it. Garrett Rooney already posted it: http://www.ccrc.wustl.edu/pub/chuck Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Chuck Cranor's PhD thesis on VM
Ronald G Minnich wrote: > I am sorry I brought this up without a URL :-( > > I'm working on it. Chuck Cranor's home page: http://www.ccrc.wustl.edu/pub/chuck/ His dissertation (for his D.Sc., not Ph.D.), "The Design and Implementation of the UVM Virtual Memory System", is a large (270 page) PostScript file: http://www.ccrc.wustl.edu/pub/chuck/psgz/diss.ps.gz Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Where is ftp.FreeBSD.org?
I've been trying to lookup ftp.FreeBSD.org for the last couple of hours and getting timeouts and other silly stuff. Can anybody give me an IP address please? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where is ftp.FreeBSD.org?
Matthew Jacob wrote: > > I've been trying to lookup ftp.FreeBSD.org for the last couple > > of hours and getting timeouts and other silly stuff. > > > > Can anybody give me an IP address please? > > Looks like it got swallowed. Try a mirror? There are oodles... Can you name one? I mean a mirror that doesn't send you to ftp.FreeBSD.org for security patches etc, which is what happens on the mirrors I've tried -- they seem to mirror the html stuff only ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where is ftp.FreeBSD.org?
"Dan Langille" wrote: > On 31 Jan 2001, at 13:51, Greg Black wrote: > > > Can you name one? I mean a mirror that doesn't send you to > > ftp.FreeBSD.org for security patches etc, which is what happens > > on the mirrors I've tried -- they seem to mirror the html stuff > > only ... > > look for yourself: > > http://freebsdmirrors.org/ Tried it recently? Gets me the same failed lookups as ftp.freebsd.org at present. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where is ftp.FreeBSD.org?
Mike Silbersack wrote: > On Tue, 30 Jan 2001, Mike Silbersack wrote: > > > Yeah, there are definite dns problems. It does still resolve here, though > > - you must be especially unlucky. > > Nevermind, ftp.freesoftware.com purged itself from my cache. ftp2+ still > seem to work fine, though. Ah, thanks for that. I'd tried the Australian mirrors and they had none of the recent stuff needed for the security updates; but I found the files I wanted on ftp2.freebsd.org, which I hadn't known about previously. > /me sighs about the evilness of CNAME Don't get me started on that :-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: regular coding?
> does anyone know a good programming > (C) mailing list I could subscribe too? Not as such. However, there are two usenet groups that cover C: comp.lang.c and comp.lang.c.moderated. If you have no news access, the c.l.c.m moderator has said he could probably set up a mail<->news gateway for that group. Let me know if you need this. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Trailing slashes and rmdir - POLA broken
Observe the following: $ uname -rs FreeBSD 4.1-RELEASE $ ls -l $ mkdir foo $ ln -s foo bar $ rmdir bar rmdir: bar: Not a directory So far, so good -- but look at this: $ rmdir bar/ $ ls -l total 0 lrwxrwx--- 1 gjb wheel 3 Feb 4 06:35 bar -> foo $ Oops, "rmdir bar/" ended up as "rmdir foo" and left the useless symlink bar in place. BSD/OS gives that silly "Is a directory" error message for the "rmdir bar/" case, but at least it does not actually do anything. I don't think FreeBSD should do what it does. Is there any good reason to preserve this behaviour? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Trailing slashes and rmdir - POLA broken
"Dan Langille" wrote: > On 4 Feb 2001, at 6:46, Greg Black wrote: > > > Observe the following: > > > > $ uname -rs > > FreeBSD 4.1-RELEASE > > $ ls -l > > $ mkdir foo > > $ ln -s foo bar > > $ rmdir bar > > rmdir: bar: Not a directory > > I'm quite sure that rm bar will work. Of course it works. The part you quoted was the introduction and was as it "should" be. You cut out the part with the actual question. I'll repeat it here: So far, so good -- but look at this: $ rmdir bar/ $ ls -l total 0 lrwxrwx--- 1 gjb wheel 3 Feb 4 06:35 bar -> foo $ Oops, "rmdir bar/" ended up as "rmdir foo" and left the useless symlink bar in place. What I'm saying is that the ls above should have shown the directory foo, because "rmdir bar/" should not result in doing the same as "rmdir foo". IMO, "rmdir bar/" should elicit the same response as "rmdir bar" -- "Not a directory" and no action. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Watch your devfs permissions in driver make_dev calls
On Friday, 2 February 2001 at 20:10:10 -0800, Peter Wemm wrote: > Robert Watson wrote: > >> crw-r--r-- 1 root wheel 78, 0 Dec 31 1969 pci > > This one may appear harmless, but it is not. It is trivially easy to create > an alignment fault (fatal on an alpha) with the userland pciconf tool. > We must not allow this to be used by users until the kernel part is fixed. > > Eg: try this on an alpha: pciconf -r -l pci0:x:x 0x3 - ie: read a longword > at byte offset 3 in configuration space.. kaboom! This looks like a separate issue. Presumably you can do this as root as well. pciconf should check the parameters. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
Matt Dillon wrote: > And, I would say, that for any mailer creating and deleting files in > a spool directory at a high rate, *ONLY* a filesystem with softupdates > turned on or a journaling filesystem such as XFS or ReiserFS can be > considered crash-surviveable. Synchronous meta-data updates will not > save you (EXT2FS or FFS without softupdates). It seems to me that you're saying that softupdates is now the recommended way to go -- so why does 4.2-Release still have the dire warnings in /sys/ufs/ffs/README.softupdates? Is that file obsolete, or do the warnings still apply? Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
Tony Finch wrote: > Why not just use rename(2)? To protect against the new filename > already existing? Why not just read the man page for rename(2) before making suggestions? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
mouss wrote: > At 21:25 07/02/01 +1000, Greg Black wrote: > >Tony Finch wrote: > > > > > Why not just use rename(2)? To protect against the new filename > > > already existing? > > > >Why not just read the man page for rename(2) before making > >suggestions? > > I find nothing convincing in the manpage. Could you please tell > what I am missing. Read the man page, and concentrate on the second sentence under the Description heading. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
Alfred Perlstein wrote: > * Greg Black <[EMAIL PROTECTED]> [010207 13:05] wrote: > > mouss wrote: > > > > > At 21:25 07/02/01 +1000, Greg Black wrote: > > > >Tony Finch wrote: > > > > > > > > > Why not just use rename(2)? To protect against the new filename > > > > > already existing? > > > > > > > >Why not just read the man page for rename(2) before making > > > >suggestions? > > > > > > I find nothing convincing in the manpage. Could you please tell > > > what I am missing. > > > > Read the man page, and concentrate on the second sentence under > > the Description heading. > > I'm not sure if the same problem exists for link/unlink and if > the problem applies to files (not just directories), but there's > a per-FS flag "in-rename" that prevents concurrant rename(2)s on > the same FS to prevent a race where something like this can happen: > > /a/b/c > > /x/y/z > > move /a/b to /x/y and at the same time try to move /x/y to /a/b. You can't rename /a/b to /x/y or /x/y to /a/b in this situation: the destination must be empty if it's a directory and you refer to /a/b/c and /x/y/z. RTFM rename(2). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum and qmail (RE: qmail IO problems)
On Wednesday, 7 February 2001 at 13:41:29 -0800, Dan Phoenix wrote: > > btw ccd requires 2 other drives am i correct? No, you can use ccd with only 2 drives. > So i just remove /var/ basically from fstab ...raid0 2 drives together > and mount that as var...is my basic understanding. > of course of 2 separate controllers..I still don;t see why that > matters whether they are on separate controllers or not but my guess has > to do with IDE unable to multitask idea.which is leading me to think > that means down one controller? See my last message. You're close. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum and qmail (RE: qmail IO problems)
On Wednesday, 7 February 2001 at 13:31:26 -0800, Matt Dillon wrote: > > In anycase, while VINUM is great for striping disks I recommend that > you use CCD to begin with, because CCD is a whole lot less complex. > You can stripe IDE drives but the two drives must be on different IDE > controllers (not just primary secondary, but each drive must be primary > on its own controller). Then striping will help. I'd contest that. I find configuring ccd very confusing. But recall that error recovery with ccd is extremely primitive. With Vinum you can add mirroring on the fly, and if a mirror dies, the volume carries on running. > Of course, I would not recommend using IDE at all if you are > pushing 600MB/day in mail. You really should be using a SCSI > based system... something like the VALINUX boxes (running > either Linux or FreeBSD). If you have only one drive per IDE controller, performance can be very good. You definitely don't want more than one drive, though. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vinum and qmail (RE: qmail IO problems)
On Wednesday, 7 February 2001 at 13:16:44 -0800, Dan Phoenix wrote:
> On Wed, 7 Feb 2001, Andrew Reilly wrote:
>> On Tue, Feb 06, 2001 at 12:13:57PM -0800, Alfred Perlstein wrote:
>>> * Andre Oppermann <[EMAIL PROTECTED]> [010206 12:07] wrote:
>>>> Does sendmail even use fsync()?
>>>
>>> It better. :)
>>
>> Quick grep of the sendmail sources shows most of the six fsync
>> calls protected by a flag (SuperSafe && or nofsync &&). I don't
>> know what circumstances can provoke either of those flags to be
>> zero, but if they can be, then it mightn't be doing any fsyncs.
>
> I went over to postfix to see if it did better.in fact it did on
> freebsd but still same problem with I/O. SOlution from talking to
> some people late last night would be to add another harddrive and
> stripe it with another drive using vinum. As you all know IDE does
> not do multitasking unlike scsi. My question is this vinum
> product...i beleive the superceder of ccdtaking another
> harddrive and striping it with the root ide drive would in theory
> destroy all contents of first IDE? Or can this volume manager take
> say a partition of first ide drive and made to work with another ide
> drive? Trying to figure out at this point whether concept is 2 other
> drives striped together say..using raid 0 or I can get away with
> just one other one. Thx in advance.
At the moment there are two issues:
1. Vinum requires that all file systems be made out of subdisks in a
"drive", which is really a partition. A drive has 265 sectors of
config and label information at the beginning, so unless you have
this space available, you can't turn a ufs partition into a Vinum
object. You can convert the first file system after swap to Vinum
by shrinking the swap and moving the start of the drive to 265
sectors before the beginning of the file system.
Even so, you wouldn't be able to stripe things in this
configuration, because striping rearranges the blocks on disk.
But I suspect that with ufs, striping won't buy you much over
concatenation, which *would* work in this scenario.
I'm planning to change things so that Vinum can import external
objects such as ufs partitions, for exactly this reason. But I
still want to be able to have at least one Vinum drive on each
spindle (i.e. physical drive), because Vinum is location
independent: you can move spindles with Vinum drives on them to
different locations (device names), and Vinum will still
understand the configuration. This requires information on the
spindle itself, of course.
2. The released version of Vinum still doesn't support a Vinum root
file system. I'm planning to work on that, but it'll take a
while.
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Cyclades Z under FreeBSD 4.2
What is the status of the Cyclades Z driver under 4.2. The cyclades site only has drivers for 3.2, NetBSD has a driver for NetBSD 1.5. I can't find any reference to a driver for freebsd 4.2. If you know of any please tell me. Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security: add md5 to suid change notification?
Nick Sayer wrote: > Would it generally be viewed as helpful to add the option of reporting > the md5 for the files listed in /var/log/setuid.*? I don't see the benefit in this if either the md5 binary or the comparison file are on writable storage (which is almost always going to be true). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: /etc/security: add md5 to suid change notification?
Nick Sayer wrote: > Greg Black wrote: > > > Nick Sayer wrote: > > > >> Would it generally be viewed as helpful to add the option of reporting > >> the md5 for the files listed in /var/log/setuid.*? > > > > I don't see the benefit in this if either the md5 binary or the > > comparison file are on writable storage (which is almost always > > going to be true). > > Then why bother checking at all? Someone can trojan ls, or even easier, > arrange to trojan suid binaries without changing the things that show up > in that listing. This is in fact my point. The automated checks are just an indicator of changes that have happened on a normally running system -- they do nothing to guarantee that nothing has been tampered with by black hats and adding the md5 checks won't change that. They add to the cost of the checks without proving anything. The existing stuff warns me when an authorised admin has replaced a setuid program so that I can take any appropriate steps if I want to. But I have to employ other strategies (with tools like tripwire and off-line or read-only storage) if I want to make serious checks on vulnerable systems. > Besides, security conscious folks could set the immutable flag for md5 > and/or the comparison file (and probably sh and ls while they're at it) > if they like. Unless things have changed, the use of elevated security levels (which are necessary if those flags are to have any force) has side effects that make them useless on lots of systems (e.g., inability to run X). Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
Matt Dillon wrote: > Yes. In general softupdates will make the entire filesystem safer. Does it make sense to use softupdates on file systems like / and /usr which have little file creation/removal? Greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
