Re: tape (sa0) on sparc64 ?
On Thursday, 16 May 2013 at 19:56:14 -0400, Zaphod Beeblebrox wrote: On Thu, May 16, 2013 at 5:08 PM, Bob Bishop r...@gid.co.uk wrote: On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: I have to retrieve some very old backups. They were made on FreeBSD and are on tape... specifically DDS4. [etc] However, attached to either controller (after a reboot of the machine and a powercycle of the drive), I get: [1:25:325]root@run:/home/foo dd if=/dev/sa0 of=tape5 dd: /dev/sa0: Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.002930 secs (0 bytes/sec) ... which is a return code of '1' and no messages on the console... I have, before you ask, tried bs=10k and 20k ... but I believe this command should run by itself fetching the first 512 bytes of each block --- narrowing down the block size logically comes after making the tape go. Try bs=64k Same result. Besides, as far as I understand, the proper operation (if the blocksize is too small) is to read the first $n bytes and then write them to the output.. The obvious question: can you write tapes and read them back? My experience with DDS tapes was of extreme unreliability. The age doesn't make things any easier. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpb7cZbaaEl8.pgp Description: PGP signature
Re: tape (sa0) on sparc64 ?
On Thursday, 16 May 2013 at 20:56:53 -0400, Zaphod Beeblebrox wrote: On Thu, May 16, 2013 at 8:30 PM, Greg 'groggy' Lehey g...@freebsd.orgwrote: On Thursday, 16 May 2013 at 19:56:14 -0400, Zaphod Beeblebrox wrote: On Thu, May 16, 2013 at 5:08 PM, Bob Bishop r...@gid.co.uk wrote: On 16 May 2013, at 21:51, Zaphod Beeblebrox wrote: [about my tape drive not working] The obvious question: can you write tapes and read them back? My experience with DDS tapes was of extreme unreliability. The age doesn't make things any easier. Well... therein lies my other suspicion. I don't have any DDS4 tapes to try writing, but the DDS3 tapes I have fail to write. ... but they don't even try. The tape spools up when inserted and mt offl works (ejects the tape) and the drive doesn't indicate any error at this point --- but it doesn't even try to start moving for either read or write. You'd expect at least a message, wouldn't you? It's difficult to say whether this is bitrot or taperot. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpHJHkO9cBto.pgp Description: PGP signature
Re: considering i386 as a tier 1 architecture
On Monday, 1 April 2013 at 0:48:08 -0400, Eitan Adler wrote: Hi, I am writing this email to discuss the i386 architecture in FreeBSD. Computers are getting faster, but also more memory intensive. I can not find a laptop with less than 4 or 8 GB of RAM. Modern browsers, such as Firefox, require a 64bit architecture and 8GB of RAM. A 32 bit platform is not enough now a days on systems with more than 4 GB of RAM. A 32 bit core now is like 640K of RAM in the 1990s. Even in the embedded world ARM is going 64 bit with ARMv8. Secondly, the i386 port is unmaintained. Very few developers run it, so it doesn't get the testing it deserves. Almost every user post or bug report I see from a x86 compatible processor is running amd64. When was the last time you booted i386 outside a virtual machine? Often times the build works for amd64 but fails for i386. Finally, others are dropping support for i386. Windows Server 2008 is 64 bit only, OSX Mountain Lion (10.8) is 64-bit only. Users and downstream vendors no longer care about preserving ancient hardware. I hope this email is enough to convince you that on this date we should drop support for the i386 architecture for 10.0 to tier 2 and replace it with the ARM architecture as Tier 1. Nice one! And only 48 minutes into the day. I've seen a number of people take it seriously. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgp6abC0YZd7B.pgp Description: PGP signature
Re: calendar(1) regressions
On Monday, 10 December 2012 at 16:27:39 +0200, Jaakko Heinonen wrote: Hi! On 2012-12-10, Greg 'groggy' Lehey wrote: Unfortunately r205821 [1] has caused several regressions to calendar(1). Relevant PRs: bin/157718 bin/162211 bin/168785 bin/170930 I think we fix bugs rather than revert the commits. Of course it's preferred but I didn't see any progress happening. As a result some of the basic functionality is broken (especially in stable/8). Maybe I should have debugged and fixed those bugs but I wasn't really keen to debug a large commit adding mostly features which I don't care much. IIRC the main issue in 8 was that debug output was appearing as a matter of course. It would be relatively trivial to MF9 (i.e. copy the 9-STABLE version), but of course that would only solve part of the problem. Do you want an MFC to 8 when I'm done? Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpUfyx3iwSIY.pgp Description: PGP signature
Re: calendar(1) regressions
On Tuesday, 11 December 2012 at 3:52:32 +0100, Julian H. Stacey wrote: Greg 'groggy' Lehey wrote: On Monday, 10 December 2012 at 16:27:39 +0200, Jaakko Heinonen wrote: Hi! On 2012-12-10, Greg 'groggy' Lehey wrote: Unfortunately r205821 [1] has caused several regressions to calendar(1). Relevant PRs: bin/157718 bin/162211 bin/168785 bin/170930 I too filed send-prs re. rgeression bugs in recent broken calendar, hopefully you can look/ fix please. bin/157718 bin/162211 These two are mentioned above. bin/15182 http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/src/gen/usr.bin/calendar/send-pr.impossible_date.no_customise This one was closed a little over 11 years ago. Since then, the code base has changed completely, but it seems that another bug (one that I'm currently scratching my head about) has overtaken it. I'll include your example in my test cases. PS for Anyone, doesnt need to be Greg misc/157748 OK, I'll take a look when I'm done here. Greg -- Sent from my desktop computer. Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpo85JBjkQbE.pgp Description: PGP signature
Re: Giant lock gone? (was: Re: ...focus, longevity, and lifecycle)
On Wednesday, 18 January 2012 at 19:58:19 -0500, Dieter BSD wrote: The original goal for 5.0 was to completely remove the Giant lock (and do other cool SMP-related stuff). Eventually it was realized that this was too big a goal to fully accomplish in 5.0 (albeit too late in the process) and the goal was changed to do the basic framework for the new SMP model; and lay the groundwork for some things run under Giant for now, and we'll remove it from them ASAP. That actually turned out to last through 6, making 7 the realization of what 5.0 was supposed to be. So you are saying that the Giant lock was completely removed in 7.0? Giant is still there in 9.0. It's a pity you didn't say who you were quoting there. To my knowledge we never intended to completely remove Giant in 5.x. We realised from the start that it would take a long time. See http://www.lemis.com/grog/diary-jun2000.php for what we decided 12 years ago. Point 6 suggests removing the Giant Kernel Spinlock, but that is misleading. We did that, and we gave the name Giant to the blocking mutex for the kernel. Previously Giant didn't have a name, because it was the only one. Greg -- Sent from my desktop computer Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpD3um6Nc84Q.pgp Description: PGP signature
Re: Porting FreeBSD to Raspberry Pi
On Thursday, 3 November 2011 at 21:05:54 -0400, Arnaud Lacombe wrote: On Thu, Nov 3, 2011 at 8:40 PM, Greg 'groggy' Lehey g...@freebsd.org wrote: On Thursday, 3 November 2011 at 11:33:25 -0400, Arnaud Lacombe wrote: On Thu, Nov 3, 2011 at 11:20 AM, Nate Dobbs misconfigurat...@gmail.com wrote: 10 year old core or not, the ARM is the worlds most widely used processor; Please read what I said correctly, I said this ARM11 is obsolete (even if still used, for sure) ... Clearly price is an issue for this device. What's so bad about ARM11 that it shouldn't be used? If you read my original comment, I did point out the $25 price tag was pretty much the only interesting thing. Now, what it has been designed for, multimedia, is going to be handled by a closed-source binary blob without datasheet, so let me turn back the question: what do you expect doing with it ? That's not turning back the question; that's a separate question. But it's a good one. I don't really see it as a multimedia device. My interest would be in little embedded agents in different parts of the house, for things like measuring temperatures. I'm sure lots of other applications will come to mind. And yes, I'll probably use the supplied Linux port. But if a FreeBSD alternative becomes available, I'd certainly prefer that. Greg -- Sent from my desktop computer Finger g...@freebsd.org for PGP public key. See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpdNNTHmHUqI.pgp Description: PGP signature
Re: GSoC: BSD text tools
On Tuesday, 25 May 2010 at 16:16:10 -0700, Bakul Shah wrote: If you must kick groff out, why not port plan9 troff which now does unicode, has 27 macro packages including ms, weighs in at about 10K lines of C code written by Joe Ossanna, Brian Kernighan, Ken Thompson, Jaap Akkerhuis others, is now open source (subject to Lucent Public License), and traces its lineage back to Joe Ossanna's original troff? There is also pic, tbl, eqn and grap (for drawing graphs). Also troff2html. AFAIK plan9 troff doesn't do dvi but I think most people can live with that. This sounds too good to be true. I'd certainly be in favour of such a change, *if* it proves feasible. Greg -- See complete headers for address and phone numbers. This message is digitally signed. See http://www.lemis.com/grog/email/signed-mail.php for more details. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpSi596nYGgU.pgp Description: PGP signature
Re: GSoC: BSD text tools
On Monday, 24 May 2010 at 21:17:01 +0200, Joerg Sonnenberger wrote: On Mon, May 24, 2010 at 12:13:07PM -0700, Charlie Kester wrote: Is the thinking that groff has only been in base to support manpages? If so, this project makes sense. But even so, some clarification of the intent is needed. The use of (g)roff for anything but man pages is practically non-existent. I wrote two books in it. It's good for typesetting. It's pretty much useless for man pages. Greg -- See complete headers for address and phone numbers. This message is digitally signed. See http://www.lemis.com/grog/email/signed-mail.php for more details. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpLO0jskKTbv.pgp Description: PGP signature
Re: GSoC: BSD text tools
On Monday, 24 May 2010 at 22:43:37 +0300, Kostik Belousov wrote: On Mon, May 24, 2010 at 09:17:01PM +0200, Joerg Sonnenberger wrote: On Mon, May 24, 2010 at 12:13:07PM -0700, Charlie Kester wrote: I welcome this change, but groff is used for much more than manpages. What happens to pic, tbl, and the other troff-related little languages? How can you say mdocml is completely replacing groff if it doesn't support those kinds of things? tbl(1) is going to be supported fully at some point in the future. It is work-in-progress. I am not sure if pic(1) is actually used beyond the groff documentation, at least I don't remember anything in NetBSD where I checked. Similiar usage is found for eqn(1). Is the thinking that groff has only been in base to support manpages? If so, this project makes sense. But even so, some clarification of the intent is needed. The use of (g)roff for anything but man pages is practically non-existent. If you want to use it for typesetting, you can always install it. Would it support ps/dvi output ? If it refers to groff, it always has supported PostScript. It's trivial to create PS output from man pages at the moment. I don't see dvi output as an interesting goal. Greg -- See complete headers for address and phone numbers. This message is digitally signed. See http://www.lemis.com/grog/email/signed-mail.php for more details. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpbWIGur1saf.pgp Description: PGP signature
Re: GSoC: BSD text tools
On Wednesday, 26 May 2010 at 1:21:20 +0300, Eitan Adler wrote: On 5/25/2010 9:52 AM, Julian Elischer wrote: BSD has always been ab;e to produce it's documentation as part of its build Please keep this true. This is what mdocml will be for. I never advocated removing the utilities required for building documentation from the base - just the soon to be superfluous groff utility (once the GSOC project is done). But groff *is* a tool required for building documentation. There are more documents than mdoc in the source tree. And there's no reason to remove groff just because you're introducing mdocml. mdocml is possibly a good idea; a better one IMO would be to replace the whole mdoc crud with something better, produce tools to format it, and leave groff the way it is. Then you could migrate the man pages gradually. Greg -- See complete headers for address and phone numbers. This message is digitally signed. See http://www.lemis.com/grog/email/signed-mail.php for more details. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgpzV0SZ3avOA.pgp Description: PGP signature
Re: our little daemon abused as symbol of the evil
On Tuesday, 2 February 2010 at 13:09:29 -0800, Kirk McKusick wrote: Thanks for the pointer. As you note, the damage (or benefit :-) is done. Still I have sent an email to the editor at Spiegel notifying them of my copyright in the hopes that they will at least ask in the future. FWIW, much as I dislike Der Spiegel, I think you targeted the wrong people. They clearly took it from the original paper (http://www.iseclab.org/papers/sonda-TR.pdf). The authors are Thorsten Holz, Gilbert Wondracek (both at the TU Wien), Engin Kirda (Eurecom, Sophia Antipolis) und Christopher Kruegel (UCSB), in case anybody knows any of them. Greg -- See complete headers for address and phone numbers. This message is digitally signed. If your Microsoft MUA reports problems, please read http://tinyurl.com/broken-mua pgp6QVedSuDRf.pgp Description: PGP signature
Re: Remote kernel debugging in FreeBSD using serial communication
On Saturday, 17 January 2009 at 17:57:10 -0800, Kamlesh Patel wrote: Hi All, I am trying remote kernel debugging in FreeBSD using serial communication. I got the following link. http://www.ibm.com/developerworks/aix/library/au-debugfreebsd.html#list1 This article is inaccurate in a number of points, notably building the kernel. I'd recommend that you read the document at http://www.lemis.com/grog/Papers/Debug-tutorial/, which also gives you much more information about the debugging process. My problem is my developing and target system does not have DS25 female port. It doesn't have to be DB25, and it doesn't have to be female. Anyone have any idea about Remote kernel debugging in FreeBSD using DS9 F/F Serial cable or any other remote debugging idea? That should work just as well. There's nothing special about the link. But if you have any alternatives, don't use an async serial cable for kernel debugging. It's glacially slow, and people have had all sorts of problems with it in the course of time. Firewire is much better, and you may even find that the hardware is cheaper. Greg -- See complete headers for address and phone numbers. pgpG8aCfwvUvZ.pgp Description: PGP signature
Why doesn't autoconf like zsh? (was: Why doesn't autoconf like our /bin/sh?)
On Sunday, 9 March 2008 at 15:27:12 -0400, Mike Meyer wrote: I've stumbled on to an obscure problem with autoconf 2.61, and I'm not sure quite what to do with it. I've already sent mail to the autoconf folks, but I'd like to understand what's going on. The problem is that, on a FreeBSD system with only /bin/sh and the ports zsh as installed shells, if you have SHELL set to zsh when invoking the autoconf-generated configure script, the script produces a broken Makefile. It doesn't generate an error, it just complains that: ... Setting SHELL to /bin/sh, or unsetting it, also solves this. This is pretty clear that this is a zsh issue, either because of bugs in zsh or (more likely, I'd guess) in autoconf. Greg -- See complete headers for address and phone numbers. pgpLIuVRXmxfW.pgp Description: PGP signature
Re: Remote GDB howto
On Monday, 3 September 2007 at 10:58:54 +0400, Andrey V. Elsukov wrote: Hi, I want to debug my kernel with modules through serial console. I have two machines with 7.0-CURRENT. What i do: ... What i've missed? You're a bit sketchy on the details that I've omitted here. What happens between these two lines? (kgdb) target remote /dev/cuad0 (kgdb) add-symbol-file /path/to/local/copy/of/file You should have some communication with the remote machine between these two lines. Have you followed my tutorial? http://www.lemis.com/grog/Papers/Debug-tutorial/ Greg -- See complete headers for address and phone numbers. pgpvvvq8o9PY5.pgp Description: PGP signature
Re: what happened to make world?
On Thursday, 30 August 2007 at 21:20:13 +0200, Pietro Cerutti wrote: # make world WARNING: make world will overwrite your existing FreeBSD installation, kill your cat and burn your house down... Now, THIS is quite funny... do you really thing that a person with - root access - the knowledge of the existence of make world needs this sort of things? I'm sure they do, especially since things have changed. There are many good reasons for this change, but it saddens me. It used to be possible to run 'make world', and indeed we advertised how easy it was. But when problems crept in, instead of fixing them, we broke 'make world' up into small pieces. Greg -- See complete headers for address and phone numbers. pgp94giZOA41f.pgp Description: PGP signature
Can anybody terminate an IP-IP tunnel for me?
In a few weeks' time I'll be moving house, and it looks as if the new address currently doesn't have ADSL, so I'll be forced to use satellite again. I've done some investigation, and the costs don't look too prohibitive, but almost nobody is prepared to route my /24 net block (192.109.197.0/24). One alternative would be to route the block through an IP-IP tunnel from somewhere else in the Internet. I see a couple of potential problems with this approach: * I need somebody to provide the service. Do you know of anybody who can help here, for a reasonable price, or can you help yourself? Somewhere in Australia would be better, but given the satellite delay it could be almost anywhere in the world. I'd be looking to route about 2 GB a month, and the download speed of the satellite link is limited to 1 MB/s. * How do I terminate the IP-IP tunnel at my end? The last time I used it, I had a static IP address for the end of the link, and another for the end of the tunnel, which implies routing that address. This won't work in the scenario I'm looking at. Is it possible to route the tunnel to the same address as the external interface IP address? Alternatively, is there another way to handle this issue? Greg -- See complete headers for address and phone numbers. pgppgZ3boUE0Z.pgp Description: PGP signature
Re: Patch for Intel 5000X hardware (ata and ichsmb)
On Sunday, 13 August 2006 at 23:02:56 -0400, Reed A. Cartwright wrote: Freebsd wouldn't recognize my hard drive contoler, so I modified a patch I found on the stable list, adding all the device ids I found in Intel's documentation. Please add this to the stable or current branch. Below is the patch, I made with respect to 6.1-Release-p3. It works with both i386 and amd64. Thanks for the patch. To ensure that it doesn't get lost between here and the source tree, can you please enter it as a PR? Greg -- See complete headers for address and phone numbers. pgpGmLTArKQrB.pgp Description: PGP signature
Re: Re: Programs not accepting input?
On Friday, 21 July 2006 at 14:32:04 +0100, Robert Watson wrote: On Fri, 21 Jul 2006, Greg 'groggy' Lehey wrote: I've been keeping a closer eye on my problem. I'm using fvwm1 with click-to-focus and lose-focus-on-screen-switch. If I move from one screen to another and quickly click on a window, the border changes colour to indicate that it has focus but keyboard input is ignored. This is likely an fvwm1 problem. I use it too (without 2 monitors) and after some time something gets broken in its focus handling, and the windows stop getting focus. Restarting fvwm clears up the problem. In my case, it's erratic. I suppose I could try restarting the window manager next time a window freezes. I've occasionally also had weird focus problems with KDE. Among other things, it looks like occasionally the mouse release event is lost somewhere in the system (or something along these lines) -- I don't know if it's a driver problem, a moused problem, an X11 probem, or a KDE problem. If I press and release each of the buttons, especially the third button, things will often recover. As long as the button is held down, KDE doesn't switch the focus and other events are largely ignored. Odd, eh? Indeed. Initially it doesn't look like my problems, where things hang up permanently. I've now tried the suggestion I made above, restarting the window manager. It didn't make any difference.e Greg -- See complete headers for address and phone numbers. pgpjhTUNTmmWW.pgp Description: PGP signature
Re: Programs not accepting input?
On Friday, 21 July 2006 at 23:38:00 +0930, Daniel O'Connor wrote: On Friday 21 July 2006 23:02, Robert Watson wrote: I've occasionally also had weird focus problems with KDE. Among other things, it looks like occasionally the mouse release event is lost somewhere in the system (or something along these lines) -- I don't know if it's a driver problem, a moused problem, an X11 probem, or a KDE problem. If I press and release each of the buttons, especially the third button, things will often recover. As long as the button is held down, KDE doesn't switch the focus and other events are largely ignored. Odd, eh? One thing that IS a KDE problem is having it manage 2 distinct desktops (ie :0.0 [laptop LCD] and :0.1 [TV out]) - it occasionally decides to give the other display focus after a dialog has been closed.. Are you sure? This sounds like the issue that Peter and I have been discussing in the context of fvwm. Makes using kmail annoying because the only way to bring back focus is to use the mouse :( Which reminds me of the reason for click focus in the first place: on the machines of 15 years ago, focus following the cursor could place an unacceptable load on the X server. Maybe what we're seeing here is related. Greg -- See complete headers for address and phone numbers. pgpwP9gmNSdN8.pgp Description: PGP signature
Re: Programs not accepting input?
On Thursday, 20 July 2006 at 18:37:08 +1000, Peter Jeremy wrote: To resurrect a fairly old thread... On Mon, 2006-Mar-27 11:23:42 +1030, Greg 'groggy' Lehey wrote: On Sunday, 26 March 2006 at 19:17:19 +1100, Peter Jeremy wrote: My work system runs separate X servers on two heads (rather than ximerama) and I have problems with windows occasionally refusing to accept focus after I move the pointer from screen to screen (though I can get an alternative window to accept focus and then switch back to the window I originally wanted). This started after an X.org upgrade but I'm not sure which one. Interesting. I've seen this one too: my mail window is at the left of the right-hand monitor on wantadilla (:0.1). Frequently when I move from :0.0 to :0.1, the window manager will highlight the window on :0.1, but focus remains with some window on :0.0. If I move further right and then back again, focus catches up with the correct window. I've been keeping a closer eye on my problem. I'm using fvwm1 with click-to-focus and lose-focus-on-screen-switch. If I move from one screen to another and quickly click on a window, the border changes colour to indicate that it has focus but keyboard input is ignored. If the target is an xterm, the cursor stays as a hollow rectangle instead of being filled - it looks like the WM knows that the window has focus but either forgets to tell the client or the client loses the message. It I leave the mouse in the target window for a while before clicking (maybe a few hundred msec) then all works correctly. I wonder if some X events are being delayed and misordered. Yes, this seems possible. I'd say that you're describing the same problem as I do above. That's mainly irritating; the problem I describe above is annoying. Did you get anywhere in debugging it? Not really. It seems to be happening less often now. Greg -- See complete headers for address and phone numbers. pgpeS9lBctok7.pgp Description: PGP signature
Re: Re: Programs not accepting input?
On Thursday, 20 July 2006 at 6:31:08 -0500, Sergey Babkin wrote: From: Peter Jeremy [EMAIL PROTECTED] To resurrect a fairly old thread... On Mon, 2006-Mar-27 11:23:42 +1030, Greg 'groggy' Lehey wrote: On Sunday, 26 March 2006 at 19:17:19 +1100, Peter Jeremy wrote: My work system runs separate X servers on two heads (rather than ximerama) and I have problems with windows occasionally refusing to accept focus after I move the pointer from screen to screen (though I can get an alternative window to accept focus and then switch back to the window I originally wanted). This started after an X.org upgrade but I'm not sure which one. Interesting. I've seen this one too: my mail window is at the left of the right-hand monitor on wantadilla (:0.1). Frequently when I move from :0.0 to 0:1, the window manager will highlight the window on :0.1, but focus remains with some window on :0.0. If I move further right and then back again, focus catches up with the correct window. I've been keeping a closer eye on my problem. I'm using fvwm1 with click-to-focus and lose-focus-on-screen-switch. If I move from one screen to another and quickly click on a window, the border changes colour to indicate that it has focus but keyboard input is ignored. This is likely an fvwm1 problem. I use it too (without 2 monitors) and after some time something gets broken in its focus handling, and the windows stop getting focus. Restarting fvwm clears up the problem. In my case, it's erratic. I suppose I could try restarting the window manager next time a window freezes. That's mainly irritating; the problem I describe above is annoying. Did you get anywhere in debugging it? BTW, I've promised Greg a script to dump the X protocol from binary log, then I was busy and and forgot about it. Is there still any interest in this tool? I'd certainly be interested. It would still be a challenge to catch the event that causes the freeze, though. Are you thinking of anything that ethereal can't do? Greg -- See complete headers for address and phone numbers. pgpf2gbdVWlD0.pgp Description: PGP signature
Re: gdb able to debug both fbsd and linux binaries
On Sunday, 9 July 2006 at 7:52:32 -0400, Alexander Kabaev wrote: On Sun, 9 Jul 2006 11:46:53 +0200 Divacky Roman [EMAIL PROTECTED] wrote: is it able to somehow make gdb be able to debug fbsd and linux binaries at the same time? I mean.. alter somehow the way its built in buildworld or something Just use Linux gdb to debug Linux binaries. Unless something broke recently, it should work fine. This used to work, even for kernel debugging. If it doesn't any more, it's a regression. Greg -- See complete headers for address and phone numbers. pgpShSa0ZlYJr.pgp Description: PGP signature
Re: dump(8) performance
On Wednesday, 31 May 2006 at 8:05:21 -0700, Eugene M. Kim wrote: While watching the output of iostat -dxz -w10 -n100 to monitor the progress/performance of a dump(8) process straight to a tape, I found out something interesting and disappointing at the same time: The disk read throughput was exactly twice as high as the tape write throughput, throughout the entire dump phases 4 and 5, i.e. dumping actual inodes. Disappointing, because the tape drive utilization (%busy) was lingering around 35%-50% for most of the time; I didn't expect the disk would be the bottleneck. :p I want to believe that this indicates a bug in dump(8) which causes each disk block to be read twice, but being no UFS expert in any sense, I wonder: Could this behavior be by design, and would there be any room for improvement? Without looking at the code, this seems unlikely. But you might get more information by attaching a ktrace to the dump process for a short period of time (find the pid, then ktrace -ppid to start trace, ktrace -ppid -C to stop again). If you do that, let me see no more than 30 lines of repetitive trace. Greg -- See complete headers for address and phone numbers. pgpbFLHhXJTNg.pgp Description: PGP signature
Re: Weight of an IRIS 4D/210GTX Box anyone ?
On Saturday, 8 April 2006 at 23:11:59 +0800, Kathy Quinlan wrote: Hi all, I have been offered a IRIS 4D/210GTX SGI box, and I need to know the rough weight, thought as google did not turn up anything and SGI seem to disown all the old stuff these days, anyone got any idea on the weight of this ? There's a photo of my 4D/25 (badged as a Control Data Cyber 910) at the right on the last photo of http://www.lemis.com/grog/old-office.html . I'm not sure how they compare. Greg -- See complete headers for address and phone numbers. pgpHupfkKa4O7.pgp Description: PGP signature
Re: Re: Programs not accepting input?
On Monday, 27 March 2006 at 7:03:23 -0600, Sergey Babkin wrote: Same here. As mentioned in the original message, I can use the mouse to open a new window under firefox. The new window will accept keyboard input, the old one won't. It's almost as if it's deadlocking on input. Reminder: my final question was how do I go about debugging this problem?. Does it happen with any kind of programs? No. So far I've only seen it with firefox, emacs and kklondike. If yes, it would probably be something focus-related (and you'd be able to see that the Focus event is not coming in). As already mentioned, this is not the case. I've seen this kind of problem too. The focus management and the highlighting of the window manager decoration are not physically connected in any way, so a bug in the window manager might cause it to do the highlighting but forget to give the focus to the application. But mouse focus and keyboard focus are the same, right? The windows respond to the mouse, but not to the keyboard. The remainder of your reply seems to build on the assumption that there is no focus. I'll leave it there in case I misunderstood and you want to refer to it. To debug that you can add debugging printout to the WM. Or I've had a script that sort of decoded the X protocol, so if you can get the dump of these (maybe with ktrace), you can decode the dump and see what happens with the focus. I'll look for it in my archives. If no, it might be something with the keyboard event translation to keysyms/text. You can debug this by writing a test program that would do it own dispatch loop - i.e. call XEvent() and then XtDispatchEvent() (or some close names - I might not remember them right), and print the debugging messages. So if you see that XEvent() is getting events but then nothing comes out of dispatching them, then the translation is broken somewhere. I might be able to find this kind of a program in my archives too, I'll look around. thanks. BTW, one place where the keyboard events might disappear is the Input Method handling code. But I don't think that you run any Input Methods. Not explicitly. Greg -- See complete headers for address and phone numbers. pgpKxcplWbAnS.pgp Description: PGP signature
Re: Re: Programs not accepting input?
On Monday, 27 March 2006 at 20:30:52 -0500, Mike Meyer wrote: In [EMAIL PROTECTED], Greg 'groggy' Lehey [EMAIL PROTECTED] typed: The focus management and the highlighting of the window manager decoration are not physically connected in any way, so a bug in the window manager might cause it to do the highlighting but forget to give the focus to the application. But mouse focus and keyboard focus are the same, right? There isn't a mouse focus. Mouse events are tied to window they happen in, not the one with focus. If you use a window manager that doesn't change the keyboard focus on mouse events, it's possible to have mouse events happen in a window that doesn't have the focus. Ah, good to know. That changes things somewhat. Greg -- See complete headers for address and phone numbers. pgpXBFQQPhFVN.pgp Description: PGP signature
Re: Programs not accepting input?
On Sunday, 26 March 2006 at 19:17:19 +1100, Peter Jeremy wrote: On Sun, 2006-Mar-26 17:50:09 +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. Here's an overview (system names are simply to show that they're different machines). Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? The latter. It's not a question of focus. My work system runs separate X servers on two heads (rather than ximerama) and I have problems with windows occasionally refusing to accept focus after I move the pointer from screen to screen (though I can get an alternative window to accept focus and then switch back to the window I originally wanted). This started after an X.org upgrade but I'm not sure which one. Interesting. I've seen this one too: my mail window is at the left of the right-hand monitor on wantadilla (:0.1). Frequently when I move from :0.0 to 0:1, the window manager will highlight the window on :0.1, but focus remains with some window on :0.0. If I move further right and then back again, focus catches up with the correct window. That's mainly irritating; the problem I describe above is annoying. The fact that new firefox windows accept input suggests that it's somewhere in X. What X server? echunga: vendor string:The X.Org Foundation vendor release number:60801000 X.Org version: 6.8.1 wantadilla: vendor string:The X.Org Foundation vendor release number:60802000 X.Org version: 6.8.2 I don't think that the difference in version numbers is the issue. Greg -- See complete headers for address and phone numbers. pgpCdQYWKKAL5.pgp Description: PGP signature
Re: Programs not accepting input?
On Sunday, 26 March 2006 at 1:36:57 -0600, Rick C. Petty wrote: On Sun, Mar 26, 2006 at 05:50:09PM +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. snip One thing that the machines have in common is that they all run x2x I noticed very similar problems on both 5.4-stable and 6.0-RELEASE boxes running xorg. I've never used x2x, but I was running x11vnc, which I ended up assuming was the culprit. It's a really strange behavior-- I would have two rxvts side-by-side, one accepting keyboard input and the other I had to cut/paste text using the mouse. It was even more frustrating when it would happen in gaim mozilla windows! The same gaim process wouldn't accept keyboard input in the conversation window but the buddy window did responded to commands (e.g. control-A brought up the accounts window). Yes, this sounds quite close to what I'm experiencing. On Sunday, 26 March 2006 at 15:43:07 -0600, Rick C. Petty wrote: On Sun, Mar 26, 2006 at 07:17:19PM +1100, Peter Jeremy wrote: Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? My problem wasn't about focus. I know the window had input focus (my settings change the border color for focused windows), but the keyboard events weren't accepted by certain clients. Same here. As mentioned in the original message, I can use the mouse to open a new window under firefox. The new window will accept keyboard input, the old one won't. It's almost as if it's deadlocking on input. Reminder: my final question was how do I go about debugging this problem?. Greg -- See complete headers for address and phone numbers. pgpFe3Z0Zr29L.pgp Description: PGP signature
Programs not accepting input?
In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. Here's an overview (system names are simply to show that they're different machines). - System echunga, running a version of the klondike game that used to come with the X distribution. - System wantadilla, running firefox. After it refuses keyboard input, I can open a new window with the mouse, and the new window accepts input. The old one still doesn't. - The same problem again with system teevee. wantadilla had what I think were hardware problems a couple of weeks ago, so I changed the entire system board and memory (but kept the disks). The new system is stable, but the problems continue. echunga and teevee have been up for months: echunga up 49+02:25, 1 user, load 0.60, 0.50, 0.35 teeveeup 100+22:08, 0 users, load 0.06, 0.31, 0.28 tvremote up 36+21:07, 0 users, load 0.18, 0.04, 0.01 wantadillaup 18+02:44, 3 users, load 0.46, 0.38, 0.49 One thing that the machines have in common is that they all run x2x (which joins X servers). echunga and wantadilla run one instance, and teevee runs another instance with tvermote, which I don't think has shown any problems. I've been running x2x for years as well, and only one of the machines has had a software upgrade anywhere near the time when the problem began. Here are the versions: FreeBSD echunga.lemis.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Sun Feb 5 14:15:02 CST 2006 [EMAIL PROTECTED]:/usr/obj/src/FreeBSD/6-STABLE/src/sys/ECHUNGA i386 FreeBSD teevee.lemis.com 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #4: Sun Mar 13 14:58:24 CST 2005 [EMAIL PROTECTED]:/usr/obj/src/FreeBSD/TEEVEE/src/sys/TEEVEE i386 FreeBSD tvremote.lemis.com 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD wantadilla.lemis.com 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Tue Jul 12 11:57:56 CST 2005 [EMAIL PROTECTED]:/usr/obj/src/FreeBSD/6-CURRENT/src/sys/WANTADILLA i386 Does this ring a bell with anybody? Any idea how to start debugging? The fact that new firefox windows accept input suggests that it's somewhere in X. Greg -- See complete headers for address and phone numbers. pgpltKtSsRkhW.pgp Description: PGP signature
Van Jacobson's network stack restructure
Last week, at the Linux.conf.au in Dunedin, Van Jacobson presented some slides about work he has been doing rearchitecting the Linux network stack. He claims to have reduced the CPU usage by 80% and doubled network throughput (he expects more, but it was limited by memory bandwidth). The approach looks like it would work on FreeBSD as well. I spoke to him and he confirmed. He's currently trying to get the code released as open source, but in the meantime his slides are up on http://www.lemis.com/grog/Documentation/vj/. Yes, this is my web site. The conference organizers are going to put it up on their web site soon, but in the meantime he's asked me to put it were I can. Comments? Greg -- See complete headers for address and phone numbers. pgpgvFs1DpfT6.pgp Description: PGP signature
Daemon image with a beer mug?
I'm just putting the finishing touches on a paper that I'll present at the AUUG 2005 conference (see http://www.auug.org.au/ for details). The paper is about using FreeBSD to control the fermentation process. Normally I put a beastie image at the bottom right of the slides (see http://www.lemis.com/SMPng/AUUG2001/slides.pdf for an example), but in this case it would seem appropriate to have the beastie holding a mug of beer. I seem to remember having seen something like that once, but I can't trace it. If you know where there is one, please let me know. Greg -- See complete headers for address and phone numbers. pgp8grgjMFhOy.pgp Description: PGP signature
Suurce code navigation tools with call graph?
I'm currently in the position of needing to cut a large program into two halves and insert a clean API between them. To do this I need to get a good understanding of how the control flow works, and I'm looking for tools that might help me. So far I've seen: - etags will follow the control flow downwards with the find-tag command (M-. in Emacs). It's useful at times, but a little pedestrian for what I want to do. - cscope will show me all callers for a function. This is closer, but it's still not overly easy to read. - Source navigator (snavigator) gives a graphical representation of the downwards control tree for a function. It doesn't seem to be able to go in the other direction, i.e show what functions call a specific function. - doxygen does the same thing. Arguably the graphic representation is nicer. - kscope is a KDE wrapper for cscope. It seems to come closest to what I'm looking for in that it will show the callers, but the form in which it does so is painful. In particular, there doesn't seem to be any way to view the source code round the call. If that's the best there is, I can live with it. But is it the best? Does anybody have a better tool? And yes, I've looked through /usr/ports/devel, but with 1536 ports, it's easy to miss things. Greg -- The virus contained in this message was not detected. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgpOTWvUhSOCt.pgp Description: PGP signature
Re: Porting on FreeBSD 53
[severely trimmed] On Friday, 13 May 2005 at 12:45:12 -0500, Sen C. Farley wrote: On Fri, 13 May 2005, Hervé Kergourlay wrote: Seán C. Farley a écrit : On Thu, 12 May 2005, Seán C. Farley wrote: On Thu, 12 May 2005, Hervé Kergourlay wrote: 4) wait() API 2 problems, the first is a ECHILD error on a wait call after a fork fork The code is generic for most of unix system. Is there any specific problems to manage the fork and wait APIs ? the second problem with calls is a blocking wait() call in the same condition but this time the son process is finished but the wait call in the father stays blocked, again it's a generic Unix code If there is no evidence, ask me for more informations The second problem sounds like what I am encountering (http://www.freebsd.org/cgi/query-pr.cgi?pr=77818) with zsh for my shell. You did suspend (sigsuspend()) SIGCHLD before the fork? By Ah ha! I see the problem that has been causing me this problem and probably you too. Signal suspensions (only these?) are not being copied with a double fork(). Here is an example program[1] to illustrate. They do get copied on FreeBSD-4.10 and Linux. I just do not know if they are supposed to be copied. I test your sample it's working on Linux and FreeBSD 4.0 but failing on FreeBDS 5.2 et 5.3. the process stays blocked on the suspend call I rewrite another sample with the same model, joined here, as we wrote it in our main program. It's working also on Linux but failing on all FreeBSD included FreeBSD 4.0, 5.2 et 5.3 ... the wait call return with an errno ECHILD ?? The children are exiting before the parents (due to sleep()'s) get to their wait()'s. did you have any idea if the problem will be solve by the FreeBSD team or not ? I updated my bug report and tried to notify David Xu but the e-mail server rejected the e-mail (too many Received headers). I am also Cc'ing Greg Lehey since he ran into a possibly similar bug[1] in February. Now that I've had time to look at it, both problems appear to be related to signals, but that's about as far as it goes. I wouldn't expect any connection unless it's a general signal race condition. Greg -- See complete headers for address and phone numbers. pgpzBmvixO1u4.pgp Description: PGP signature
Re: Porting on FreeBSD 53
[much irrelevant content removed] On Friday, 13 May 2005 at 12:45:12 -0500, Sen C. Farley wrote: On Fri, 13 May 2005, Hervé Kergourlay wrote: did you have any idea if the problem will be solve by the FreeBSD team or not ? I updated my bug report and tried to notify David Xu but the e-mail server rejected the e-mail (too many Received headers). I am also Cc'ing Greg Lehey since he ran into a possibly similar bug[1] in February. 1. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/77537 This doesn't ring a bell. I'm currently travelling (the long way back from BSDCan), and I won't be home for another week. I'll look when I get home. Greg -- See complete headers for address and phone numbers ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: style(9) example :-)
On Thursday, 17 March 2005 at 19:33:50 +0300, Roman Kurakin wrote:
Hi,
I was unable to refrain from posting this :-)
int i;main(){for(;i[]i;++i){--i;}];read('-'-'-',i+++hell\
o, world!\n,'/'/'/'));}read(j,i,p){write(j/p+p,i---j,i/i);}
There used to be a whole culture of this sort of thing. My favourite
one is an anagram generator:
#include stdio.h
long a
[4],b[
4],c[4]
,d[0400],e=1;
typedef struct f{long g
,h,i[4],j;struct f*k;}f;f g,*
l[4096 ]; char h[256],*m,k=3;
long n (o, p,q)long*o,*p,*q;{
long r =4,s,i=0;for(;r--;s=i^
*o^*p, i=i*p|(i|*p)~*o++,*q
++=s,p ++);return i;}t(i,p)long*p
;{*c=d [i],n(a,c,b),n(p,b,p);}u(j)f*j;{j-h
=(j-g =j-i[0]|j-i[1]|j-i[2]|j-i[3])4095;}v(
j,s)f* j; {int i; for(j-k-kv(j-k, ' '),fseek(
stdin, j-j, 0);i=getchar(),putchar(i-'\n'?i:s),i-
'\n';);}w(o,r,j,x,p)f*o,*j;long p;{f q;int
s,i=o-h;q.k=o;ri?j=l[r=i]:ri
(s=r~i)?(s|=s1, s|=s
2,s|=s4,s
|=s8
,j=l[r
=((ri
|s)~(s1))-1i]):0;--x;for
(;x!(pi);p=1);for(;!xj;n(o-i,j-i,q.
i),u(q),q.g||(q.j=j-j,v(q,'\n')),j=j-k);for(;x;j=x
?j-k:0){for(;!j((r=(ri)-1i)-i(rp)?2:(x=0));j=l[r]);!
x||(j-g~o-g)||n (o-i,j-i,q.i)||(
u(q), q.j=j -j,q.g?w(q
,r,j-k,x ,p):v(q,
'\n'));}}y(){f
j;char*z,*p;
for(;m ? j.j=
ftell( stdin)
,7,(m= gets(m ))||w(
g,315 *13,l[ 4095]
,k,64* 64)0:0;n(g
.i,j.i,b)||(u (j),j.
k=l[j.h],l[j.h]= j,y())){for(z= p=h;*z(
d[*z++]||(p=0)););for(z=p?n(j.i ,j.i,j.i)+h:;
*z;t(*z++,j.i));}}main(o,p)char** p; {for(;m = *++p;)for(;*m-
'-'?*m:(k= -atoi(m))0;d[*m]||(d[*m ]=e,e=1),t(*m++,g.i)); u(
g),m=h
,y();}
To run it, you need a dictionary such as /usr/share/dict/web2. For
example:
gson free software foundation/usr/share/dict/web2
gson obfuscated c contest/usr/share/dict/web2
gson unix international /usr/share/dict/web2
gson george bush /usr/share/dict/web2
gson bill clinton/usr/share/dict/web2
gson ross perot /usr/share/dict/web2
gson paul e tsongas /usr/share/dict/web2
Greg
--
See complete headers for address and phone numbers.
pgpuVrWFfvjSy.pgp
Description: PGP signature
Setting maximum data size
I've spent the last hour trying to raise the maximum process data size (ulimit -d). /etc/login.conf says unlimited, /boot/loader.conf has nothing, and I can't find a sysctl that looks like it's doing something nasty. I've RTFMd and found nothing. What am I missing? Greg -- See complete headers for address and phone numbers. pgpzlx2AvdmIh.pgp Description: PGP signature
Re: Setting maximum data size
On Thursday, 3 March 2005 at 17:40:35 -0800, Brooks Davis wrote: On Fri, Mar 04, 2005 at 12:06:22PM +1030, Greg 'groggy' Lehey wrote: I've spent the last hour trying to raise the maximum process data size (ulimit -d). /etc/login.conf says unlimited, /boot/loader.conf has nothing, and I can't find a sysctl that looks like it's doing something nasty. I've RTFMd and found nothing. What am I missing? The FM seems faily unhelpful, but the answer is the tunable kern.maxdsiz. I found it by finding MAXDSIZ in NOTES and the searching for it on Robert's FreeBSD Cross Refrence and finding the one .c file that used it: http://fxr.watson.org/fxr/ident?i=MAXDSIZ Heh. Yes, I recall doing something like that too. In fact, I had guessed at it based on the entries in /boot/defaults/loader.conf, but it still took me 3 attempts to get it right. Some values can be specified like this: hw.physmem=1G# Limit physical memory. See loader(8) That doesn't seem to work for MAXDSIZ. I ended up setting it like this: kern.maxdsiz=2147483648 # Set the max data size It would be nice to get somebody to update the FM. Thanks for the reply. Greg -- See complete headers for address and phone numbers. pgpjLSbFoNhak.pgp Description: PGP signature
Re: Help about debugging FreeBSD kernel core dump file
[Format recovered--see http://www.lemis.com/email/email-format.html] Single line message. On Tuesday, 1 March 2005 at 11:41:08 +0800, River wrote: Hi, Everyone: How can I debug the core dump file created by kernel panic? I try to use gdb -core vmcore.0 (vmcore.0 is 4G file because I have 4G memory) and the gdb said: this is not a vaild core file. Why? Processor dumps have a different format for core dumps. Depending on the version of FreeBSD, you use one of these forms: (older)gdb -k kernel.debug vmcore.0 (newer)kgdb kernel.debug vmcore.0 You'll need a kernel compiled with debug symbols to make much sense of the dump. See http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf for more details. 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 See complete headers for address and phone numbers. pgpCIb9kvd0Ft.pgp Description: PGP signature
Re: Above the law? (was: You gotta be kidding .... Re: cvs commit: src/sys/miscfs/specfs spec_vnops.c)
On Sunday, 16 January 2005 at 17:30:51 +, Linus Caldwell wrote: On Sunday, 16 January 2005 at 11:46:35 -0700, Matthew Dillon wrote: I can't believe this. Poul has completely ignored the proposal, time table, sysctl, and the several major figures that supported it and has gone ahead with his own plans, refusing to work with or accept the advise of anyone else on the matter. I believe Poul's action to be entirely improper and, frankly, if it were up to me I'd pull both his core status and his commit privs for this third direct infraction. [Although this is formally a reply to Matt, I'm addressing the committers community here] About 5 years too late? Greg -- See complete headers for address and phone numbers. pgp1aBuovLV42.pgp Description: PGP signature
Re: Printing from kernel
On Thursday, 7 October 2004 at 0:31:33 +0400, Roman Kurakin wrote: Hi, I have some problems with printing from kernel. At first I think that my problems was cause I use printf, but changed all of them to log cause it safe to use from interrupt handlers. The situation become better but I still observe system lockup in case I output some debug information from my driver. About the only thing I can think is that you're doing this in some area where it's unsafe to print, probably holding a lock that's needed in the print routines. Also I have some problems with system console via com port. Instead of messages from kernel I see the first letter of the month name. Could anybody comment my observation? Without more detail, it's impossible to help. Does anybody saw anything like this? No. printf() is widely used in the kernel. Oh, I forget to say I observe that with both Current and Releng5, SMP. Also I can't trigger NMI so I can't see the point of lockup. Take a look at your code and check what locks you're holding. Also, if this is only for debugging, you should be using the kernel debugger. Greg -- See complete headers for address and phone numbers. pgpYJ4Myqltru.pgp Description: PGP signature
Re: remote debugging question
On Monday, 27 September 2004 at 11:07:21 -0700, Jerry Toung wrote: Good morning list, I CAN connect to the target but the 'bt command return #0 0x in ?? () at the remote. That suggests that you're not connected. So this is what I am doing, hopefully somebody can tell me what I am missing. I have 2 laptops same brand and model, both running 6.0current and same kernel config. laptop A panics because of kld I am writing and I want to debug A with laptop B. I reboot A and login and enter CTRL-ATL-ESC to get db prompt, then enter 'gdb', then enter 's'. At this point I don't get the db prompt anymore and A seems to be in a loop, is that normal? Yes. It's not in a loop, it's waiting for remote gdb. on laptop B, the only thing I did is get the copy of kernel.debug.A in /usr/obj/usr/src/sys/MYKERNEL You'll need the sources as well, but that's the next problem, not the one you're experiencing. I 'cd' to that location an run kgdb file kernel.debug.A set remotebaud 1 That's obviously wrong. This is the bit rate of the serial connection. I don't know what gdb does with such a speed (0.1 bytes per second), but it looks like it ignores it. set remotebreak 1 set debug remote 1 target remote /dev/cuaa0 it connects, on B screen (not using X) I see Warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: shared library handler failed to enable breakpoint Sending packet: $qSymbol ::#5...Ack Packet Received: Packet qSymbol (symbol-lookup) is NOT supported This looks like a communication problem. Typically the connection should run at 9600 bps (well, it should run as fast as it can, but we've had problems above that speed). gdb has been significantly changed in the last few months, and it's possible that I'm out of date with some details. It's also possible that this is a bug that crept in there, but I'd first check the bit rates. My personal favourite for remote debugging is firewire. If you have the hardware, you should use it. I'm working on documentation, but there's a fair amount in gdb(4). The format of the fwcontrol and dconschat EUI64s has changed, and the man page needs changing as a result (doc committers please note). It should be obvious, though. when I type 'bt', that's where I get #0 0x in ?? () Yes, that's what I thought. Please somebody advise since I can't do anything with that. And laptop A is still hanging/loop, and no prompt. If you can't get the connection to work with the correct bit rate, you'll have to reset and reboot it. Greg -- See complete headers for address and phone numbers. pgpDVsAswY2PA.pgp Description: PGP signature
Re: add-symbol-file
[Format recovered--see http://www.lemis.com/email/email-format.html] Important output wrapped. On Friday, 17 September 2004 at 17:02:58 -0700, Jerry Toung wrote: Hello list, Could somebody tell me why I can't list the source code of this kld? I built the module with COPTS=-g, it is loaded in the kernel and I run kgdb in /usr/obj/./MYKERNEL. Everything seems to go well, except kgdb still doesn't like it. However if I run kldsyms, it only loads acpi.ko.debug and I can list it. It looks like you're not doing it the way it was intended. As it says: Type 'getsyms' after connection to load kld symbols. This does the add-symbol-file for you. Take a look at gdb(4) for more details. If you're debugging a local system, you can use 'kldsyms' instead to load the kld symbols. That's a less obnoxious interface. doadump () at pcpu.h:159 (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 I'm assuming that this was broken by your MUA, and it's not the way you put it in, which must have been: (kgdb) add-symbol-file /usr/local/src/nren-6.0current/osr_src/if_osr.ko 0xc24b3184 -s .data 0xc24b6900 -s .bss 0xc24b6cc0 Where did you get these addresses from? They're all outside the bounds of the kld as shown below. (kgdb) kldstat During symbol reading, Incomplete CFI data; unspecified registers at 0xc05ff7d1. Id Refs AddressSize Name 14 0xc040 5d63e4 kernel 2 14 0xc09d7000 54784acpi.ko 31 0xc2326000 6000 if_osr.ko In any case, I'm not sure that you need getsyms any more. It used to be needed to get round various gdb restrictions. What happens if you don't do anything? If that doesn't work, how about running getsyms, as suggested? Please let me know either way what happens. 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 See complete headers for address and phone numbers. pgpAR9BrOG0SH.pgp Description: PGP signature
Re: debugging kld panic
On Wednesday, 8 September 2004 at 11:01:33 -0700, Jerry Toung wrote: Good morning Greg, I am trying to debug a kld that I wrote that keeps causing panics. I already did a search on the mailing list, and the only useful info I got was an email you replied to in 1999, Re: debugging a panic in a kld-ed kernel. You refered to .gdbinit.vinum.paths but I couldn't find it. I am running 6.0current, then you gave out this: But not for 6-CURRENT. The kld symbols should get loaded automatically, so you don't need to do anything. You should see something like: Reading symbols from /usr/obj/usr/src/sys/ZAPHOD/modules/usr/src/sys/modules/dcons/dcons.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/ZAPHOD/modules/usr/src/sys/modules/dcons/dcons.ko.debug Reading symbols from /usr/obj/usr/src/sys/ZAPHOD/modules/usr/src/sys/modules/dcons_crom/dcons_crom.ko.debug...done. Loaded symbols for /usr/obj/usr/src/sys/ZAPHOD/modules/usr/src/sys/modules/dcons_crom/dcons_crom.ko.debug This is all you need. I copied and past it in a file and made it executable, but no success. Could you be kind enough and let me know what to do to debug my kld. You can reply to hackers since I am also on that list. I am sure this will benefit more than one person. This should be generally known. There's also a man page gdb(4) which explains this and more. Greg -- Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgpJ2myoXyd9K.pgp Description: PGP signature
Re: Serial consoles and remote GDB
On Monday, 30 August 2004 at 14:11:49 -0400, Rob Deker wrote: Stephan Uphoff wrote: Are you sure that your serial line is configured with the right baud rate? This may seem a stupid question, but how do I set the baudrate on the port and in gdb? The default bit rate is 9600 bps. It would be nice to go higher, but there appear to be race conditions which make it unreliable. At least initially, you should run at 9600 bps; after that, there are ways of changing the rate that are themselves changing. Check the kernel configuration files and sysctl. To set the bit rate on the port depends on what software you're using. I still use cu, though it's now gone from the base system, along with its parent uucp. With cu you'd do: cu -s 9600 -l /dev/cuaa0 You can do something similar with tip, which is still around. If you have a firewire connection, that's *much* better. Before you say no, I don't have that, consider that firewire hardware is very cheap. There's some stuff about it in http://www.lemis.com/papers/AUUG2004/tutorial.pdf, but it would be nice if somebody were to extract this information and put it in the handbook. If anybody wants to, please contact me and I'll supply the source. Greg -- See complete headers for address and phone numbers. pgpnt1L4OaTOX.pgp Description: PGP signature
Re: What mouse? (was: Samsung Cordless Mouse)
On Tuesday, 17 August 2004 at 20:18:42 -0500, Sean Farley wrote: On Wed, 18 Aug 2004, Greg 'groggy' Lehey wrote: On Tuesday, 17 August 2004 at 11:13:17 -0500, Sean Farley wrote: On Tue, 17 Aug 2004, Greg 'groggy' Lehey wrote: This mouse has five buttons: the normal three on top, and one on each side. I can't find a way to get the side buttons to work, and looking on the web hasn't shown anything of interest. I assume you mean in X as opposed to moused although moused appears to support at least five buttons according to its man page. No, this is with moused. It still needs to initialize the mouse. Will you be using moused on the console? No. It is not needed to run X. I know. Without a reason to change, I won't. - Preferably cordless. Cord mice tend to wander a little when you let go of them, and that's a real nuisance on a high-resolution display. Maybe you can find a cord-to-cordless converter--there is bound to be an engineer that has done this :)--if you find a mouse you like that just happens to have a tail. That would defeat the purpose of it being cordless. Greg -- Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgpPsTnUu8Ica.pgp Description: PGP signature
What mouse? (was: Samsung Cordless Mouse)
On Tuesday, 17 August 2004 at 11:13:17 -0500, Sean Farley wrote: On Tue, 17 Aug 2004, Greg 'groggy' Lehey wrote: This mouse has five buttons: the normal three on top, and one on each side. I can't find a way to get the side buttons to work, and looking on the web hasn't shown anything of interest. I assume you mean in X as opposed to moused although moused appears to support at least five buttons according to its man page. No, this is with moused. It still needs to initialize the mouse. This may help with your X issues: http://www.xfree86.org/current/mouse5.html#22 Yes, been through all of that and more. Nothing worked. In the meantime I've connected it up anyway as a 3 button mouse and decided I really don't like it; the buttons are far too heavy in their action, and it's difficult to move it sideways without pressing one of the side buttons. So this is not much of an issue any more. Can anybody recommend a good mouse? My criteria are: - Middle button easy to use. The current crop of mice has the middle button integrated with the roller, and that makes the middle button either heavy or easy to confuse with the roller. - Preferably cordless. Cord mice tend to wander a little when you let go of them, and that's a real nuisance on a high-resolution display. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgpwu5Aa4Hg84.pgp Description: PGP signature
Samsung Cordless Mouse
More by accident than by design, I find myself the owner of a Samsung PS/2 Cordless Mouse. To make identification easier, it doesn't have a model number, so I assume it's the only one they made. This mouse has five buttons: the normal three on top, and one on each side. I can't find a way to get the side buttons to work, and looking on the web hasn't shown anything of interest. I don't suppose anybody knows this mouse, though I'd be interested in hearing if somebody has. My real question is: how can I enable the side buttons? There's obviously some kind of initialization sequence that is performed by the Microsoft drivers included with the mouse, but how do I find out what they do? Is there some utility that runs under Microsoft and snoops what's going on on the PS/2 port? I know of something similar for USB, but so far I've drawn a blank for PS/2. Greg -- When replying to this message, please copy the original recipients. If you don't, I may ignore the reply or reply to the original recipients. For more information, see http://www.lemis.com/questions.html Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp39QNnRrSeu.pgp Description: PGP signature
Re: problem with gdb
On Sunday, 25 April 2004 at 20:42:07 +0200, GiZmen wrote: Hello, I have problem with gdb. When i start gdb as a regular user or even user i wheel group, i cant debug program that i want. I start gdb with my program and i set breakpoint and i run this program. And i do not stop i this breakpoint. gdb prints output and this message: Program exited normally. You can't do that without a process to debug. and it return to gdb prompt. When i do the the same as root it works perfectly. I dont have any idea what is the cause of this problem. Looks like you're debugging a setuid executable. By the time you hit the breakpoint, the process has changed its euid, and you can no longer stop it. Greg -- Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Remote Debugging using GDB on Linux
On Tuesday, 20 April 2004 at 3:17:56 -0500, William M. Grim wrote: Hi! Is it possible to do remote debugging of the FreeBSD kernel over a serial connection using Linux? FreeBSD has a special -k switch that Linux does not for GDB; so, I'm not even sure it's possible without a lot of work. I haven't tried it that way round, but I have debugged a Linux kernel over a serial line with FreeBSD gdb. That suggests that it might work the other way round, too. Unfortunately, my experience with NetBSD doesn't bear this out: I can debug a NetBSD kernel with FreeBSD gdb, but not the other way round. Greg -- Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Serious bug in vinum?
On Tuesday, 30 March 2004 at 14:37:00 +0200, Lukas Ertl wrote:
On Fri, 26 Mar 2004, Joao Carlos Mendes Luis wrote:
I think this should be like:
if (plex-state plex_corrupt) { /* something accessible,
*/
Or, in other words, volume state is up only if plex state is degraded
or better.
You are right, this is a bug,
No, see my reply.
The correct solution, of course, is to check if the data is valid
before changing the volume state, but turn might turn out to be a
very complex check.
Well, the minimum correct solution is to return an error if somebody
tries to access the inaccessible part of the volume. That should
happen, and I'm confused that it doesn't appear to be doing so in this
case.
On Tuesday, 30 March 2004 at 11:07:55 -0300, Joo Carlos Mendes Lus wrote:
Greg 'groggy' Lehey wrote:
On Tuesday, 30 March 2004 at 0:32:38 -0300, Joo Carlos Mendes Lus wrote:
Basically, this is a feature and not a bug. A plex that is corrupt is
still partially accessible, so we should allow access to it. If you
have two striped plexes both striped between two disks, with the same
stripe size, and one plex starts on the first drive, and the other on
the second, and one drive dies, then each plex will lose half of its
data, every second stripe. But the volume will be completely
accessible.
A good idea if you have both stripe and mirror, to avoid discarding the
whole disk. But, IMHO, if some part of the disk is inacessible, the volume
should go down, and IFF the operator wants to try recovery, should use the
setstate command. This is the safe state.
setstate is not safe. It bypasses a lot of consistency checking.
One possibility would be:
1. Based on the plex states, check if all of the volume is still
accessible.
2. If not, take the volume into a flaky state.
3. *Somehow* ensure that the volume can't be accessed again as a file
system until it has been remounted.
4. Refuse to remount the file system without the -f option.
The last two are outside the scope of Vinum, of course.
Discussion?
--
Note: I discard all HTML mail unseen.
Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.
pgp0.pgp
Description: PGP signature
Re: Serious bug in vinum?
On Tuesday, 30 March 2004 at 0:32:38 -0300, Joo Carlos Mendes Lus wrote:
Sorry for the cross-posting, but nor the Author nor freebsd-bugs did
acknowledge my message, and I think this is a very serious bug in vinum,
leading to loss of data...
If these are not the correct foruns for this, please forgive me and
tell me which is the correct one.
PS: Please CC: me, since I'm not currently subscribed to these
lists.
Sorry for the lack of response. Yes, I saw it, and so did Lukas Ertl,
and we've been discussing it. This list is probably not the best.
Hi Greg,
I've been a big fan of vinum since it's beggining. I use it for RAID0
and RAID1 solution for lots of servers.
In some RAID0 (stripe) configurations, though, I've had some serious
problems. If an underlying disk fails, the respective plex and volume do
not fail, as they should. This leads to full corruption of data, but worst
of that, leads to a system which believes the data is safe. In one ocasion,
for example, the backup ran and overwrote good data with bad data, full of
zeros.
I am not fully aware of vinum programming details, but a quick look at
4.9-STABLE, in file vinumstate.c, dated Jul, 7, 2000, at line 588, function
update_volume_state() sets volume state to up if plex state is corrupt or
better for at least one plex:
for (plexno = 0; plexno vol-plexes; plexno++) {
struct plex *plex = PLEX[vol-plex[plexno]]; /* point to the plex */
if (plex-state = plex_corrupt) { /* something accessible,
*/
vol-state = volume_up;
break;
}
}
I think this should be like:
if (plex-state plex_corrupt) { /* something accessible,
*/
Basically, this is a feature and not a bug. A plex that is corrupt is
still partially accessible, so we should allow access to it. If you
have two striped plexes both striped between two disks, with the same
stripe size, and one plex starts on the first drive, and the other on
the second, and one drive dies, then each plex will lose half of its
data, every second stripe. But the volume will be completely
accessible.
I think that the real issue here is that Vinum should have returned an
I/O error for accesses to the defective parts. How did you perform
the backup?
Greg
--
Note: I discard all HTML mail unseen.
Finger [EMAIL PROTECTED] for PGP public key.
See complete headers for address and phone numbers.
pgp0.pgp
Description: PGP signature
Strange instructions in compiler output (was: A simple question)
On Friday, 5 March 2004 at 13:43:04 -0500, Chungwei Hsiung wrote: Hello.. I am super new to this list, and I have a simple question that I don't know why it does that. I have a simple test program. I compile it, and gdb to disassemble main. I got the following.. 0x80481f8 main: push %ebp 0x80481f9 main+1: mov%esp,%ebp 0x80481fb main+3: sub$0x8,%esp 0x80481fe main+6: and$0xfff0,%esp 0x8048201 main+9: mov$0x0,%eax 0x8048206 main+14:sub%eax,%esp 0x8048208 main+16:movl $0x804a6ce,0xfff8(%ebp) 0x804820f main+23:movl $0x0,0xfffc(%ebp) 0x8048216 main+30:sub$0x4,%esp 0x8048219 main+33:push $0x0 0x804821b main+35:lea0xfff8(%ebp),%eax 0x804821e main+38:push %eax 0x804821f main+39:pushl 0xfff8(%ebp) 0x8048222 main+42:call 0x804823c execve 0x8048227 main+47:add$0x10,%esp 0x804822a main+50:mov$0x0,%eax 0x804822f main+55:leave 0x8048230 main+56:ret I don't know if at line 5, we move zero to %eax. why do we need to sub %eax, %esp? why do we need to substract 0 from the stack pointer?? Any help is really appreciated. This is probably because you didn't optimize the output. You'd be surprised how many redundant instructions the compiler puts in under these circumstances. Try optimizing and see what the code looks like. If this *was* done with optimization, let's see the source code. Greg -- Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Strange instructions in compiler output
On Friday, 5 March 2004 at 18:43:11 -0500, Chungwei Hsiung wrote: Greg 'groggy' Lehey wrote: On Friday, 5 March 2004 at 13:43:04 -0500, Chungwei Hsiung wrote: Hello.. I am super new to this list, and I have a simple question that I don't know why it does that. I have a simple test program. I compile it, and gdb to disassemble main. I got the following.. 0x8048201 main+9: mov$0x0,%eax 0x8048206 main+14:sub%eax,%esp ... I don't know if at line 5, we move zero to %eax. why do we need to sub eax, %esp? why do we need to substract 0 from the stack pointer?? Any help is really appreciated. This is probably because you didn't optimize the output. You'd be surprised how many redundant instructions the compiler puts in under these circumstances. Try optimizing and see what the code looks like. If this *was* done with optimization, let's see the source code. Hello.. thank you very much for the reply I actually don't know how to use the optimization. Use the gcc command line options. See below. I just compile it with gcc 3.2.2, and use gdb to disassemble main to get this assembly. Is it possible I can get the non-redundent output? here is the code I compile.. ... The best way to look at the assembly output is to generate it directly from the compiler. I get: $ cc -O -pipe -mcpu=pentiumpro -S exec.c $ cat exec.s .LC0: .string /bin/sh ... main: pushl %ebp movl%esp, %ebp subl$24, %esp andl$-16, %esp movl$.LC0, -8(%ebp) leal-8(%ebp), %edx movl$0, 4(%edx) movl-8(%ebp), %eax movl%eax, (%esp) movl%edx, 4(%esp) movl$0, 8(%esp) callexecve movl$0, %eax movl%ebp, %esp popl%ebp ret This doesn't look that much like your code. Without the -O (optimize) flag I get: $ cc -pipe -mcpu=pentiumpro -S exec.c $ cat exec.s ... main: pushl %ebp movl%esp, %ebp subl$24, %esp andl$-16, %esp movl$0, %eax subl%eax, %esp movl$.LC0, -8(%ebp) So yes, it looks as if you're not optimizing. Greg -- Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: best choice for RAID1: vinum(8) or VIA VT8237
On Saturday, 21 February 2004 at 22:43:21 +0100, Burkard Meyendriesch wrote: Hello Greg, for my new -CURRENT box I have to decide wether to use vinum(8) or the on-board capabilities of my Asus K8V Deluxe motherboard. Which solution would you recommend? Well, I'd use Vinum, of course. Your mileage may vary, and it depends on exactly what you want to do. Greg -- Note: I discard all HTML mail unseen. Finger [EMAIL PROTECTED] for PGP public key. See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Kernel Debugging
On Tuesday, 3 February 2004 at 11:55:42 -0800, Julian Elischer wrote: On Tue, 3 Feb 2004, Sridhar Chellappa wrote: How do we debug a freeBSD kernel ? Do we have something similar to KGDB that linux offers ? there is a whole chapter in the handbook about this.. Unfortunately, it's a little out of date. If you're using -CURRENT, you should also look at gdb(4). Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: GEOM + Vinum
On Wednesday, 21 January 2004 at 12:35:52 +0100, Josef El-Rayes wrote: Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: And to answer another message: yes, Vinum on FreeBSD *must* be adapted to GEOM. There's no other solution. shouldn't we add this as a task item to the releng schedule? That sounds reasonable. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: GEOM + Vinum
On Tuesday, 20 January 2004 at 14:51:08 +0100, Lukas Ertl wrote: On Tue, 20 Jan 2004, Dag-Erling Smørgrav wrote: Lukas Ertl [EMAIL PROTECTED] writes: following the recent discussion about GEOM and Vinum I wrote some proof-of-concept code, or rather, I copy'n'pasted the necessary stuff for a prototype. Of course it's ugly, it's buggy, it's by far not complete, but at least it understands the most basic setup: a volume with a single plex and a single subdisk. This is great! Thanks! I was actually hoping to get a little more feedback, since I'm not so sure if I'm going into the right direction, and I'd like to hear what people say about it before I dive into hacking it more, and there was virtually no feedback at all. I'm sure you were expecting to hear from me. Sorry about that, but I've just got back from a very intensive conference, and I still have over 2000 messages to catch up on. I'm certainly very happy to see that you've done this work, and as soon as I get some time I'll try it out here. And to answer another message: yes, Vinum on FreeBSD *must* be adapted to GEOM. There's no other solution. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Wednesday, 14 January 2004 at 22:32:32 +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Lukas Ertl writes: On Mon, 12 Jan 2004, Robert Watson wrote: I think the right strategy is to follow the minimalist approach now (adopt the disk(9) API, rather than having Vinum generate character devices) so that swap works on Vinum again, and so that when UFS moves to speaking GEOM there's no loss of functionality. If we want to completely reimplement Vinum, we should do that separately so as to avoid loss of functionality during structural changes. As many ways lead to Rome, how about the following scenario. I don't know if it's a clever way to do things, and I don't know if it's even possible to with GEOM, so some input is appreciated. *) Have separate GEOM classes for each of the different vinum objects (drive, sd, plex, volume). *) Let the drive geom taste the slices configured for vinum, read the on-disk config and then spawn the necessary other geoms (I'm not sure if the latter can be done in GEOM). *) I think this is a clean implementation, since the GEOM framework offers all the background needed to transform the IO requests. *) It would also be a good way to clean up the vinum code. It is possible in GEOM, but I am not convinced that fragmenting into this many GEOM classes can be classified as an easy path to go. I think it's probably a good ultimate aim, but I don't think it should be the first step. I think for now the important thing is to get the people interested on this collected on a mail-alias, and for them to discuss how the can work together to make something happen. After that, try to define something closer. A mailing lists exists. [EMAIL PROTECTED] If somebody wants to put in a FreeBSD version, that wouldn't be a disadvantage. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Sunday, 11 January 2004 at 12:08:24 +0100, Alexander Leidinger wrote: On Sun, 11 Jan 2004 15:46:49 +1030 Greg 'groggy' Lehey [EMAIL PROTECTED] wrote: [missing attribution to phk] I'd say lets kick them both into perforce and let whoever wants their hands have a go at them. For some definition of perforce, I'm all for it. Note that there's also an OS-independent mailing list (see http://www.auug.org.au/mailman/listinfo/vinum-devel for joining instructions). I'm a little bit confused. I've read Pouls mail as an suggestion to remove vinum from -current and let people modify it in the perforce repository. If I got this wrong, please tell me and everything is fine, but if I got it right, do you (Greg) agree to remove it from -current? No. As others have said, if phk and I agree, the world will come to an end. I'm saying: 1. Yes, let people hack at it and improve on it outside the source tree. 2. If it works, don't fix it. At the moment, Vinum works, for some definition of works. These two aren't incompatible. Removing existing functionality for the sake of purity, on the other hand, is unnecessary. Sadly, much as I love the discussion, I have this conference next week, starting in less than 12 hours, and I need to sleep first. Unless the shit hits the fan, don't expect to hear from me for a week. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Future of RAIDFrame
On Saturday, 10 January 2004 at 18:12:28 -0700, Scott Long wrote: Alexander Leidinger wrote: On Sun, 11 Jan 2004 00:12:57 +0100 Poul-Henning Kamp [EMAIL PROTECTED] wrote: As much as I would hate to see RF and Vinum disappar from our source tree, maybe what we need to do is to kick them both into training-camp in p4 while you and Greg look the other way. [...] I'd say lets kick them both into perforce and let whoever wants their hands have a go at them. RF isn't working today on -current, vinum is (please don't tell me something else, I don't want the system under my desk stop running on a vinum volume just because you say it has to :-)). Do you really want to throw your axe at vinum while it's still alive? Ok, stop right here. This is the third email so for that is attempting the debate the merits of one over the other. Spending time arguing that point is a waste of time. If working on RF is something that interests you, then show your support and say so. On Saturday, 10 January 2004 at 16:44:10 -0700, Scott Long wrote: Dag-Erling Smørgrav wrote: Scott Long [EMAIL PROTECTED] writes: I started RAIDframe three years ago with the hope of bringing a proven and extensible RAID stack to FreeBSD. I'm having trouble seeing what RF does that Vinum (or at least a properly GEOMified Vinum) can't do... Please read the RAIDframe documents at http://www.pdl.cmu.edu/RAIDframe before you ask again. People, I think we should make it clear that neither Vinum nor RAIDFrame are perfect. We shouldn't chuck either out at the moment, and it would be really nice, as phk suggests, to have people working on both. Both are rather old now, but they contain good ideas. It would certainly be an excellent idea to improve them both. We shouldn't be trying to compare their relative merits at the moment. Wait until they regain their strength. I'll answer phk's suggestions separately. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Future of RAIDFrame and Vinum (was: Future of RAIDFrame)
On Sunday, 11 January 2004 at 0:12:57 +0100, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Scott Long writes: All, I started RAIDframe three years ago with the hope of bringing a proven and extensible RAID stack to FreeBSD. Unfortunately, while it was made to work pretty well on 4.x, it has never been viable on 5.x; it never survived the introduction of GEOM and removal of the old disk layer. [...] I have a Work-In-Progress for converting and integrating it into GEOM on my home Perforce server. It hasn't been touched in several months and I really don't see myself being able to finish alone it in the near future. Since it's been hanging over my head for so long, I'm very, very close to just removing it and moving on. I can't help thinking about how small the central group of developers in FreeBSD is, and considering that you also carry the armoured release-engineer hat, I am fully able to understand why you have not been able to pull RF along in addition to all the other stuff. As much as I would hate to see RF and Vinum disappar from our source tree, maybe what we need to do is to kick them both into training-camp in p4 while you and Greg look the other way. Hmm. I can't see why they have to disappear from the source tree, and I don't see why Scott or I should have to look the other way. I don't know about RAIDFrame, but Vinum still works for the most part: apart from a couple of recently reported bugs, as well as a number of long-standing ways to shoot yourself in the foot, the only problem I know is that swap on Vinum no longer works. I had hoped to get something done about that, but it requires changing the interfaces to disk(9), and I don't have the time. In the p4 tree, we can easier add new talent to our developer force and I am pretty sure that some sort of merry band of developers would form around both RF and vinum there. OK, I'm not a fan of p4, but I suspect that's not the issue. This sounds like a way of suggesting Let's do VinumNG and RFNG and get a whole lot of people involved. I couldn't agree more. I am not convinced that they may be able to pull off the task, but the fact that somebody at least tries should give us better chances than having RF stuck in your TODO queue, and vinum stuck in Gregs, while everybody else waits more or less paitiently. Mainly less :-) I've been trying to encourage people to look at Vinum for some time. It's a relatively complicated piece of code, and something about it seems to scare people away. That's unfortunate, because the complex parts are also those that work the best. The crap around the outside, like configuration management, was slated for replacement about 4 years ago, but it never happened, though it's relatively simple code. It's gradually getting more stable, but it's a long way from being good. Because we might as well be honest and face it: Neither you nor Greg has much chance of finding the significant amount of time that you need. At least from my point of view, that's absolutely correct. I know this can be seen as you and Greg throwing in the towel, Not to me. but I urge you to try to see it like saw my Junior Kernel Hacker list: Throwing a good meaty bone to pick which I myself couldn't eat anyway. Yes, that's the way I've seen it for some time. Any ideas how to excite people? Do you want to say something? Something like If phk and grog agree, it must be right? :-) I'd say lets kick them both into perforce and let whoever wants their hands have a go at them. For some definition of perforce, I'm all for it. Note that there's also an OS-independent mailing list (see http://www.auug.org.au/mailman/listinfo/vinum-devel for joining instructions). Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Repeated messages (was: [PATCH] : libc_r/uthread/uthread_write.c)
On Monday, 6 October 2003 at 21:46:24 -0400, Dan Langille wrote: On 6 Oct 2003 at 19:10, Daniel Eischen wrote: Is your mailer screwed up? We're getting duplicates (a few days later). I don't think so. Could they have been moderated? What do the headers say? Somebody in France has set up a selective mail loop. I've seen a couple of my own messages like this. The FreeBSD postmaster is aware of the problem, but it's difficult to catch just the occasional message. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: nVidia nForce2 potential owners please read (take two)
On Monday, 29 September 2003 at 12:45:35 -0700, Tony A, Fields wrote: Thanks for your effort to get the nVidia folks to pony up the documentation. I unfortunately purchased a system that has a motherboard that uses the MCP2 network adapter chip set. I now have to rethink how I am going to configure the system as a file server that straddles the enterprise wide intranet and a local lab network while maintaining some isolation between the two. A 100 Mb/s NIC will cost you about $10. Greg -- See complete headers for address and phone numbers. NOTE: Due to the currently active Microsoft-based worms, I am limiting all incoming mail to 131,072 bytes. This is enough for normal mail, but not for large attachments. Please send these as URLs. pgp0.pgp Description: PGP signature
Re: [hackers] Re: BCM4401 ethernet driver
On Tuesday, 26 August 2003 at 20:31:22 +0100, Duncan Barclay wrote: On 26-Aug-2003 [EMAIL PROTECTED] wrote: Greetings; Wondering whatever further may have come of this discussion regarding FreeBSD support of the built-in ethernet for the Dell Inspiron 8500 Notebook. Running a dual-boot system with MS Windows XP and FreeBSD 4.8 Release since 5.1 wouldn't seem to install, but not even sure how to make use of drivers beyond including their device code in the kernel configuration file, which may just be an issue with this current release. I fixed the RX problem yesterday. Take a look at http://people.freebsd.org/~dmlb/ and grab the lastest bcm_...tar.gz file. Untar this into /sys then cd /sys/modules/bcm make make install kldload if_bcm This driver is for -current only. OK, I've tried this on my Inspiron 5100, and it works without any recognizable problems: $ time scp wantadilla:/dumpa/echunga/0/src.gz /dev/null src.gz 100% 28GB 10.0MB/s 48:41 real48m41.751s user15m41.577s sys 4m23.766s netstat -i shows: input (bcm0) output packets errs bytespackets errs bytes colls 7452 0 11280248 5373 0 361578 0 7502 0 11358028 5416 0 364512 0 7435 0 11256590 5366 0 361116 0 7504 0 11361056 5416 0 364464 0 7460 0 11292512 5384 0 362352 0 7500 0 11355000 5412 0 364200 0 7451 0 11279390 5379 0 362022 0 7503 0 11358088 5414 0 364332 0 7417 0 11228874 5359 0 360654 0 I'd say that this cut is good enough to commit to -CURRENT. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
nVIDIA nForece2, again
My main machine has just fried a southbridge, and I'm looking for a replacement. From what I can see, in the AMD range, the current best performer is the nVIDIA nForece2. I've read Bill Paul's description of the problems with the onboard NIC, and if I buy one of these boards, I'll certainly swell his mailbox of disgruntled nVIDIA customers. But at a more pragmatic level, a 100 Mb/s NIC costs nothing, and I have a few spares floating around, so it's not that big a deal. Looking at what our local suppliers have to offer, the MSI K7N2 Delta boards (http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=436) look reasonable, both in terms of performance and price. Does anybody have any experience with them? Are there any other problems with the chip set? I've heard that it has an IOAPIC on it, even for single processors. Is this an issue? Any other comments? Based on what I've read, I'd probably be putting a Barton 2600XP+ and 0.5 to 1 GB of DDR memory into it. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Broadcom 440x
On Wednesday, 13 August 2003 at 10:36:01 +1000, Michael Day wrote: Hi all. A few months ago I saw that some people were having probs finding a driver for the 440x network card installed on some onboard motherboards. Has anyone had any luck in finding drivers for these cards as I now have a dell laptop that I can\222t connect to the network (Not very useful). If anyone is aware of drivers for either the 4.x or 5.x strands of freebsd I would be most interested Duncan Barclay is working on a driver, but it's not finished yet. Do you want to help? Which model laptop do you have? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Interview in Byte with Chris Sontag/SCO and FUD relatingtoBSDsettlement agreement
On Thursday, 19 June 2003 at 1:29:37 -0700, Terry Lambert wrote: Greg 'groggy' Lehey wrote: On Wednesday, 18 June 2003 at 2:38:34 -0700, Terry Lambert wrote: Greg 'groggy' Lehey wrote: Yes, it reminded me of that thread, but wkt was actually referring to System III, not 32V. I am also pretty certain that it was widely stated at the time that the UCB's license was the older Western Electric license, which is the same license which allowed Lyon's to publish his commentary, legally, including the kernel source code. I suppose you mean John Lions. Yes. I always spell his name wrong. He got into a lot of trouble for that, and I doubt he would have got away with it in the USA. Really? Can you point to the signed non-disclosure agreement that he violated in order to publish his commentary? The U.S. was not nearly as anal about this stuff until the 1980's. Things have got worse, yes. But certainly there was enough trouble in the 70s. While the university, proper, did obtain a more modern license, that license could not be retroactive to change the terms of the original license. Which university are you talking about? UCB or UNSW? UCB. But John was at UNSW. You're in the area, aren't you? For some definition of area. UNSW is about 1400 km away. But I'll be in the area in about 6 weeks time. Why don't you ask to see the original license agreement that Lions was under at the time of his commentary's publication. I think I'll ask Greg Rose. He might have some interesting insights. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Interview in Byte with Chris Sontag/SCO and FUD relatingtoBSDsettlement agreement
On Wednesday, 18 June 2003 at 2:38:34 -0700, Terry Lambert wrote: Greg 'groggy' Lehey wrote: Yes, it reminded me of that thread, but wkt was actually referring to System III, not 32V. I am also pretty certain that it was widely stated at the time that the UCB's license was the older Western Electric license, which is the same license which allowed Lyon's to publish his commentary, legally, including the kernel source code. I suppose you mean John Lions. He got into a lot of trouble for that, and I doubt he would have got away with it in the USA. While the university, proper, did obtain a more modern license, that license could not be retroactive to change the terms of the original license. Which university are you talking about? UCB or UNSW? The original licenses were very lenient in their terms, since, at the time, the 1956 consent decreee prohibited them from making money from software sales, as part of their being a regulated monopoly at the time. It was only later, after the breakup, that they were permitted to profit from sales of their software. And that's when license fees went up. There's a difference between fees and conditions. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Interview in Byte with Chris Sontag/SCO and FUD relating toBSDsettlement agreement
On Tuesday, 17 June 2003 at 6:08:06 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Heller [EMAIL PROTECTED] writes: Will the FreeBSD project issue an offical statement relating to these allegations? What will happen to FreeBSD if SCO aims at the BSD projects. Could SCO revoke the Settlement Agreement and pursue a court ruling? This is not an official statement from the project. There is not now, nor has there *EVER* been *ANY* System V code in BSD. *EVER*. NEVER. NEVER. NEVER. Agreed. The fact that Sontag even mentions this detracts further from an already very stupid interview. I've put an analysis at http://.lemis.com/grog/sco-sontag-16jun2003.html. The IP connected with the BSD suit of the early 1990s derived from pre System V and System III versions of Unix. In fact, Version 7 unix has more Berkeley copyrights in it than ATT copyright notices. The Seventh Edition? Nope, as far as I can tell there's no BSD code there. In /usr/src: $ find .|xargs grep -i bell telephone|wc -l 27 $ find .|xargs grep -i berkeley Binary file ./cmd/learn/lib/C.a matches ./cmd/refer/test:new providence murray hill berkeley heights $ find .|xargs grep -i california|wc -l 0 Most of the Bell Telephone lines were indeed copyrights. Or did you mean something else? The settlement terms specifically state that SCO cannot sue anybody who makes a release based on 4.4-LITE. The settlement agreement is BINDING on both parties. SCO cannot revoke it, and will have a hell of a legal fight if they try. That depends on how much money we can put into the legal fight. But they don't need to do that: they can simply make the same claim that they did about Linux, that somebody has since imported UNIX code into the tree. The settlement has nothing to do with that. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Interview in Byte with Chris Sontag/SCO and FUD relating toBSDsettlement agreement
On Tuesday, 17 June 2003 at 20:41:00 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: Most of the Bell Telephone lines were indeed copyrights. Or did you mean something else? I was confused. I was recalling a thread on TUHS about Unix 32V, which I confused with 7th Edition (which I mistakenly called version 7). Yes, it reminded me of that thread, but wkt was actually referring to System III, not 32V. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Unreachable web site (was: Interview in Byte with Chris Sontag/SCOand FUD relating to BSDsettlement agreement)
On Tuesday, 17 June 2003 at 20:24:29 -0700, Doug Ambrisko wrote: Josef Grosch writes: On Wed, Jun 18, 2003 at 12:01:38PM +0930, Greg 'groggy' Lehey wrote: On Tuesday, 17 June 2003 at 6:08:06 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Martin Heller [EMAIL PROTECTED] writes: Will the FreeBSD project issue an offical statement relating to these allegations? What will happen to FreeBSD if SCO aims at the BSD projects. Could SCO revoke the Settlement Agreement and pursue a court ruling? This is not an official statement from the project. There is not now, nor has there *EVER* been *ANY* System V code in BSD. *EVER*. NEVER. NEVER. NEVER. Agreed. The fact that Sontag even mentions this detracts further from an already very stupid interview. I've put an analysis at http://.lemis.com/grog/sco-sontag-16jun2003.html. Your site seems not to be responding. Do you need a mirror? Nope he needs one less w as in: http://www.lemis.com/grog/sco-sontag-16jun2003.html Yup. does exist, however. It's really a CNAME for echunga.lemis.com, my local web server. It's firewalled off, since I'm on a dialup line. I introduced the CNAME for exactly that reason: if I cut and paste a local URL and forget to change it, people will assume it's a typo and DTRT. If I had more DNS foo I'd be able to assign different addresses to different interfaces, I suppose. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Vinum / 4.8 / Referenced disk / Recovery
On Friday, 30 May 2003 at 18:21:53 -0400, Michael G. Jung wrote: After a reboot on 4.8 I ended up with a degraded raid 5 partition... The only thing special about my setup is 4944 drives spread over 3 channels, running SMP kernel. That's a lot of drives. One sub disk was down and the and the drive was referenced... in scouring the mailing lists I saw where a referenced disk means you have referenced a non-existent drive - I read this as one vinum didn't think was defined.. in my case it was drive29 -- /dev/da29s1e I don't know how this got referenced !!! It's part of your configuration. From the printconfig output: drive drive29 device /dev/da29s1e It's been reboot many times and this has not happened. It probably hasn't failed for. So I boldly created a config file for vinum and re-created the drive. --- config file drive drvie29 device /dev/da29e --- end but I still can not start the sub disk. ([EMAIL PROTECTED]) /home/staff/mikej# vinum start raid5-1.p0.s15 Can't start raid5-1.p0.s15: Drive is down (5) ([EMAIL PROTECTED]) /home/staff/mikej# Here is what vinum thinks.. Do I rm the sub disk and re-create it? No. Will this kill my raid-5 partition ?? If you do enough messing around with the configuration, yes, you can kill your RAID-5 plex. In all probability, your drive has failed and requires replacement. You'll see that from the system log file. Look at http://www.vinumvm.org/vinum/how-to-debug.html and http://www.vinumvm.org/vinum/replacing-drive.html. You don't need to submit the information if you can understand it and take the appropriate action. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Announcing a Vinum mailing list
I've been neglecting Vinum for some time now: I have been very busy. Times are now changing, and I hope to have time to work on Vinum in the near future. To start off, I have created a mailing list [EMAIL PROTECTED] I invite you to sign up: send a message to [EMAIL PROTECTED] with the text 'subscribe vinum-devel' if you're interested. There are a number of things to do: 1. We have a Sourceforge project (at least in name), http://sourceforge.net/projects/vinum/. There's nothing on the site, and we need somebody to set it up and put a CVS tree there. 2. Atul Kabra, Ramsubramanyam and Shajid Thirvuthodi have ported Vinum to NetBSD. I have the sources, but I haven't done anything with them yet. I know that others of you are also interested in this project; we should discuss it on the list. 3. There's also interest in Vinum on OpenBSD and Linux. I'd assume that there isn't much work involved in adapting the NetBSD port to OpenBSD. Linux is definitely a different matter. I hope to see you on the list soon. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Kernel trace
On Wednesday, 12 March 2003 at 22:27:42 -0500, Yaoping Ruan wrote: Does any one know the implementation of ktrace in FreeBSD? I would like to hack the source code and have a relatively easy way to copy the kernel stack image when a certain of thing happens, such as page fault. It should work like the breakpoints in gdb. But kernel panic is too much trouble for just a single stack image, and kgdb is not simple enough. Which source file(s) I should look at? Start with kern/kern_ktrace.c. Note that work is currently going on with the implementation. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: arc4random() range
On Wednesday, 19 February 2003 at 9:22:18 -0800, Wes Peters wrote:
On Tuesday 18 February 2003 22:36, Peter Jeremy wrote:
I see this as a major advantage of arc4random() - if I want 32-bit
random numbers I don't have to call random() twice and merge the
results. I've never understood why random() was specified to return
a '0' in the MSB.
It probably had something to do with the PDP-11 architecture. This
rings a bell, but I can't recall what it was. Greg Lehey might be
able to help here, he has far better knowlege of the Good Old Days(tm)
than I do.
Difficult to say. I don't think that random() was in the Seventh
Edition. They used rand() instead. Read the code and shudder:
static longrandx = 1;
srand(x)
unsigned x;
{
randx = x;
}
rand()
{
return(((randx = randx*1103515245 + 12345)16) 07);
}
That's the entire content of Seventh Edition /usr/src/libc/gen/rand.c.
Greg
--
See complete headers for address and phone numbers
Please note: we block mail from major spammers, notably yahoo.com.
See http://www.lemis.com/yahoospam.html for further details.
pgp0.pgp
Description: PGP signature
Disk reliability (was: Tagged Command Queuing or Larger Cache ?)
On Tuesday, 29 October 2002 at 2:03:50 +, Daniel O'Connor wrote: On Tue, 2002-10-29 at 01:54, Kenneth Culver wrote: I haven't had any trouble with the WDxxxBB drives - the WDxxxAA drives are pretty unreliable though. Hrmm, I havn't tried those, but just about every WD drive I've used has ended up with problems which were of course handled by the warranty, but even then, I still had to reinstall the os and pull a bunch of stuff from my backups which was a pain to do for each failure. Like I said, just my personal experience. I don't think the new 8MB cache drives have been out long enough to actually develop the problems I've seen on WD drives though. Yes, but my point is that the AA drives are bad, but the BB drives seem good. I have been using them for a while (~1 year) without trouble. I've had trouble with BB drives. Given that they have (or had) a 3 year warranty, 1 year of experience isn't very much to go by. Personally I find that no HD manufacturer has a good reputation - they have all made trashy drives at one point. Give the general time it takes for problems to surface vs product lifetimes makes deciding what to buy a PITA :( That's a more valid point. Note that WD and Seagate have dropped their warranty on IDE drives from 3 years to 1 year. What does this say to you? Greg -- 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: I climb the mountain seeking wisdom
On Monday, 9 September 2002 at 16:31:10 -0600, Stacy Millions wrote: Greg 'groggy' Lehey wrote: On Friday, 6 September 2002 at 12:23:13 -0600, Stacy Millions wrote: Page fault while in kernel mode unfortunately, ddb hangs so I don't get a core file. That's obviously the first thing you should address. I'm open to suggestions. How can I force a core if ddb freezes? I have tried 'sysctl debug.debugger_on_panic=0', but that doesn't help, just causes me to have to hit the reset button for different reasons; like an infinite loop worth of kernel trap 12 with interupts disabled There will always be situations where the debugger can't catch the problem in time. Then it's up to you to guess and put a breakpoint just before it freezes; this can be an interative process. The method requiring the least thought is to single step over function calls until the system freezes. Then you know which function it happened in. Reboot, set a breakpoint in that function, and repeat. Debugging hasn't changed much since 4.3BSD. True enough, but *what* I am debugging sure has changed. KLD for example did not exist the last time I did kernel programming. Debugging klds is a little more difficult. You need to use gdb's add-symbol-file command to get the symbols. There are some functions which help, but the good one hasn't been committed yet. Take a look at http://people.freebsd.org/~gallatin/gdbmods. On the subject of which, I have a question regarding KLD, in my driver, the MOD_LOAD does nothing, the identify() does a BUS_ADD_CHILD() to the parent (nexus) and then probe() and attach() do thier stuff and life is good. Now I want to do a kldunload and have the driver dettach, the MOD_UNLOAD is called, but the detach() is never called. What do I need to do to get the detach() to be called? Is there an opposite to BUS_ADD_CHILD()? I tried device_delete_child()... gave me a panic and no core and devclass_delete_driver()... returned an error (ENOENT, I think) Hmm, haven't had that particular problem, but my klds don't handle hardware. Have you looked at similar code in other drivers? Greg -- 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: I climb the mountain seeking wisdom
On Monday, 9 September 2002 at 20:14:34 -0700, Terry Lambert wrote: Greg 'groggy' Lehey wrote: There will always be situations where the debugger can't catch the problem in time. Then it's up to you to guess and put a breakpoint just before it freezes; this can be an interative process. The method requiring the least thought is to single step over function calls until the system freezes. Then you know which function it happened in. Reboot, set a breakpoint in that function, and repeat. Dumping a bunch of printf's in, with Here 1\n, Here 2\n, and so on will find this problem a lot faster than an equivalent number of reboots. 8-). That depends on how well you use each tool. Greg -- 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: I climb the mountain seeking wisdom
On Friday, 6 September 2002 at 12:23:13 -0600, Stacy Millions wrote: John Baldwin wrote: On 06-Sep-2002 Stacy Millions wrote: At the moment, the whole area of Bus Resources is causing me greif, my panic rate is about 4 or 5 panics/hour (but I'm sure, with some coaching, I could get that to 7 or 8 :-) What kind of panics? Page fault while in kernel mode unfortunately, ddb hangs so I don't get a core file. That's obviously the first thing you should address. Debugging hasn't changed much since 4.3BSD. Greg -- 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
Remote kernel debugging over Ethernet (was: interrupting the remote kernel)
On Saturday, 7 September 2002 at 10:28:27 +0200, Christian Zander wrote: On Sat, Sep 07, 2002 at 12:56:12AM -0700, Julian Elischer wrote: What I found to work well is remote GDB debugging with the UDP wrapper (ip-gdb), it responds to CTRL-C as expected. huh? do we have that? (rushes of to see it it's in ports) comes back sadly.. (where do you get it from?) Yes, Tim Gilman posted about this on freebsd-hackers earlier this year, the project has been sittling idle since, but can still be found here: http://sourceforge.net/projects/ipgdb/. I did a little bit of work on it to make it work in environments with routers; I sent a patch to Tim, but have not yet heard back. I attached this updated version as a patch that should apply cleanly against 4.5+. It will work with eepro100 adapters in my version, but adding the necessary support for other NICs is trivial. The complete patch also needs to change a few lines in gdb to make it work, this is included in the original patch, but not in the one I attached. Just by coincidence, I heard of this today from Richard Sharpe of Panasas. It seems that Tim has moved on, which is possibly why you haven't heard back from him. I'd be interested in committing this code if nobody has any objections. Greg -- 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 crash
On Friday, 23 August 2002 at 15:58:17 -0500, Doug Swarin wrote: On Fri, Aug 23, 2002 at 09:20:02PM +0100, Peter Edwards wrote: Peter Edwards [EMAIL PROTECTED] wrote: Urgh. Forget it, I was seeing references to rq that weren't there. Hi, Ok, I'm up to my neck in code I've never seen and making wild guesses, but: In vinumrequest.c:launch_requests(), isn't it possible that the final BUF_STRATEGY() from line 431 completes before we get back to the top of the outer for loop and that complete_rqe gets called for the last buffer (we don't have splbio()), bringing the refcount of the entire request down to zero, then freeing the request. You then get to the top of the loop, and rq will have been freed, but you looking at its contents. Ok, maybe not likely but... I suppose you could just hold one more reference to the request while doing launch_requests() and check after all theB UF_STRATEGYs are done when you decrement the active count and find it's zero, then do the request-finished processing as done by complete_rqe Just a thought... I've already got a patch for this; it's in PR kern/41740, along with another that allows you to safely hot-revive a striped plex. I checked in the first patch a couple of hours ago. It seems that it only affected ATA drives, which is why I wasn't able to reproduce it. The second patch is less obvious. It doesn't take into account that RAID plexes are also striped. I'll discuss this with you in private mail. Greg -- 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: It's dead Jim
On Sunday, 18 August 2002 at 7:23:31 -0700, Alfred Pythonstein wrote: Mad propz to Hiten 'imbecile' Pandya, btw... It is official -- Netcraft is now confirming: *BSD is dying Mike, is that you? You don't need to be a Kreskin [amdest.com] to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood. FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying. Let's keep to the facts and look at the numbers. OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts. Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house. All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dabblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead. Fact: *BSD is dying Fact: this claim is over a year old. On Sunday, 22 April 2001 at 14:44:28 -0700, Mike Cheponis wrote: Seen on slashdot today: http://slashdot.org/comments.pl?sid=01/04/22/0056207threshold=-1commentsort=0mode=threadpid=80 We should all keep in mind this simple truth: *BSD is dying. You don't need to be Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood. Let's keep to the facts and look at the numbers. OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts. Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to another charnel house. All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS hobbyists, dabblers, and dilettantes. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead. Fact: trolls are facing hard times. Fact: trolls are dying. This one is dead, but hasn't noticed it yet. Greg -- 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: troff vs. DocBook (was: Request for submissions: FreeBSD Bi-Monthly Development Status Report (fwd))
On Wednesday, 24 July 2002 at 21:31:56 +0100, Nik Clayton wrote: On Mon, Jul 22, 2002 at 09:58:23AM +0930, Greg 'groggy' Lehey wrote: IMO the tags aren't the problem with DocBook. It's just *really* difficult to get good-looking results with. What did you think of the 2nd edition of the Handbook? That was Docbook toolchain all the way (with the possible exception of some small hand-tweaks to the finished postscript by Murray). I've taken a look at the book again. Yes, it's clean. I don't like the small fonts and the excessive leading and other vertical spacing, but I suppose that could be fixed in the style sheets. There are also a number of widows and orphans, for example the top(1) example on page 99/100. I also suspect that massaging the PostScript was to get round some annoyances of using DocBook. On Monday, 29 July 2002 at 0:00:24 -0700, Murray Stokely wrote: [CC: changed to a more appropriate mailing list, original list BCCed] On Mon, Jul 22, 2002 at 09:58:23AM +0930, Greg 'groggy' Lehey wrote: IMO the tags aren't the problem with DocBook. It's just *really* difficult to get good-looking results with. I've actually converted the FreeBSD book into DocBook (anybody want a perl script?), but jade can't format it, and gmat is a real kludge. Theoretically, DocBook is better, but I want something that works. Hey Greg, What's the problem with jade? Hmm. Looking back on what I said there, I'm jumping to conclusions. What I meant was that I needed to use gmat because it contains the O'Reilly style sheets. That's not really a jade issue. I will certainly agree that it is difficult to get good-looking results with jade, but you should at least be able to format your document and get a valid PostScript file with Norm's default stylesheets. Yes, I've been able to do that with gmat. Given that it worked (and a lot faster than jade, too), I didn't try using jade. If I had done, I fear I would have run into some horrendous problems due to my lack of understanding of the maze of configuration files. Did TeX run out of resources? Did you bump up the memory allocation in texmf.cnf? I do recall doing this in the past. This isn't really a sound-off about DocBook, just about the relative turgidity of the tools. I've tried reading the DocBook book, and I've found it very confusing. A large part of the problem, though, is simply the fact that I'm happy with troff, and I haven't seen enough advantage in DocBook to migrate to it. Greg -- 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
troff vs. DocBook (was: Request for submissions: FreeBSD Bi-Monthly Development Status Report (fwd))
On Sunday, 21 July 2002 at 17:42:17 +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bob Willcox writes: On Fri, Jul 19, 2002 at 01:32:13AM +0100, Paul Richards wrote: I wonder how true that is these days. The last time I used nroff was for my masters thesis which was in 1990! Does anyone except man page maintainers still use it in earnest? As I understand it, W. Richard Stevens wrote all of his books in troff. Of course he died a few years back so is no longer using it. But my guess is that were he still alive today, he'd still be using troff. And until somebody shows me a way to edit DocBook where 8% of my screen estate isn't occupied by the XML tags, I'll probably be using [nt]roff as well. IMO the tags aren't the problem with DocBook. It's just *really* difficult to get good-looking results with. I've actually converted the FreeBSD book into DocBook (anybody want a perl script?), but jade can't format it, and gmat is a real kludge. Theoretically, DocBook is better, but I want something that works. Greg -- 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: offtopic: low level format of IDE drive.
On Monday, 8 July 2002 at 14:46:29 -0700, Kent Stewart wrote: Julian Elischer wrote: One of my FreeBSD development boxes had a hernia last week when it lost power while writing to disk. The drive wrote out garbage to a track. I want to reformat the drive, (low level) but the bios doesn't have any support to do this (In the past That is how I did this). The machiine has 1 CD drive and no floppy.. anyone with any ideas as to how one can reformat a hard drive feel free to lend me a clue.. I had this happen to me during some power fail testing about 18 months ago with an IBM IDE disk (forget the model number). On one such power fail, I lost something like 200 sectors. All of the manufacturers have a program that will do that. Many of them even produce a bootable floppy. Check their support web page. I went looking for format utilities and didn't find anything. Finally I stuck the disk in an old 486 with a format utility in the BIOS, and that worked (fortunately the damage was below the 504 MB boundary :-). While looking at these format programs, I gained the distinct impression that they didn't really format. The description was too vague to make it clear just what they did do, though. Quite possibly it's the same as dd if=/dev/zero, and it just relocates the logical sectors. Greg -- 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: Does FreeBSD have a problem with some AMD processors?
On Friday, 31 May 2002 at 2:31:32 +0200, Morsal Rodbay wrote: I recenetly bought an Athlon XP 1800+... and it turned out that it wouldnt run XFree. Everything worked well besides X. Since a workstation without X is useless I was forced to switch to WinXP and it's very stable so there is nothing wrong with the hardware which means it's a FreeBSD issue. This is rather simplistic logic. Firstly, it could be a hardware problem which Microsoft doesn't tickle. It could be any of a number of things. From this viewpoint, I'd say that the problem is you: you don't even say what happens. We can't debug like that. FWIW, I am running dual-headed X on an Athlon 1700+ based system. I've had no problems with X at all. Greg -- 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: graphical frontend for vinum
On Wednesday, 24 April 2002 at 12:06:39 -0400, [EMAIL PROTECTED] wrote: On Wed, Apr 24, 2002 at 04:14:44PM +0200, Miguel Mendez wrote: On Thu, Apr 25, 2002 at 12:05:29AM +1000, Joshua Goodall wrote: On Wed, Apr 24, 2002 at 03:52:18PM +0200, Miguel Mendez wrote: However you present the UI, when it comes to making changes, please have it queue up the actual commands which are then visible to the sysadmin for approval, backout, single-stepping, recording etc. Way too many graphical management tools have been corrupted by the microsoft control panel c. Well, if you've used recent versions of the veritas volume manager fronted you'll notice that they give the cli command output in a window, that's what I intend to do. You might want to look at EVMS on Linux. They have a few good ideas, like building a library and API underneath the user interfaces. From what I can see, that project has some nice underlying concepts, but the user interfaces need to evolve for a few years. (Worst CLI ever, and the GUI is very confusing.) To be fair to the EVMS people, the tools are still evolving. I'd certainly like to see more documentation, though. I wonder if that API could interface with vinum? I don't think so. User interface maybe, but Vinum and EVMS have a very different API. It would be very nice to have a cross-platform library interface to operate on disk volumes. Yes, we've discussed that in the past. The problem is that EVMS, AIX LVM and Linux LVM have different objects from VERITAS and Vinum. I can't see an easy way of bringing them to a common denominator. It's hard enough explaining the two concepts in the first place. For that, it might even be worth improving the EVMS API, rather than starting from scratch. If you want to help work on EVMS, I know people would love the help. Personally I'd prefer to see work on Vinum, of course :-) Greg -- 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: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Wednesday, 24 April 2002 at 3:16:43 -0700, Terry Lambert wrote: The X11 we are talking about here is not the default X11, which is a set of distfiles, but a ports X11, which is not, but which is likely to be the basis of future distfiles. Correct. So we are really talking about an alternate set of code to provide or not provide the TCP X11 display service. More to the point, we're telling people that this is XFree86, a platform-independent package which we also supply. But it's not quite XFree86 because we've modified it. The modification in this case is very small but very far-reaching, and a newcomer would suspect the operating system, not XFree86, when he has problems. The thing that offended the hell out of everyone way that the decision was made for the future distfiles release (which is used by practically everyone) by sneaking it in the ports back door (which is used by practically no one), which, when viewed disparagingly, looks like an attempt to pull a fast one. Hmm. No, I for one wasn't offended the hell. And I really don't see any malice here: it was done with the best of intentions, but I think without a proper understanding of the consequences. Greg -- 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: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Wednesday, 24 April 2002 at 7:27:55 -0500, Jacques A. Vidrine wrote: On Wed, Apr 24, 2002 at 09:06:55AM +0930, Greg 'groggy' Lehey wrote: I think the issue here is that individuals make this kind of decision. We need a broader consensus for this kind of change. As Jochem points out, only 3 people were involved in the decision, all of them people with security profiles which weren't affected by this change. What, he should have gotten 30 reviewers? I think what is happening here is exactly what should happen: it seems like a good idea to one guy; he implements it. He shows it to a few more folks; they think it is a good idea, too. It gets committed, and the majority of people either don't notice it or believe it is a good feature. But the majority doesn't rule. The feature sits in the tree and maybe people run into problems with it. If so, it gets fine tuned or backed out. I think this is what is supposed to happen. For my part, I would like to see the change backed out and rethought. I like having the X server not doing TCP by default, but this change loses because: = It breaks existing configurations with no warning. = The option is in the wrong place (startx) and there is apparently no way to override the default. I think it would be better to just put `-nolisten tcp' in /usr/X11R6/lib/X11/xinit/xserverrc for new installations only. Then the system administrator could easily override it for all users; and at least a user can override it for herself. If he knew about it. Look at my last message to Terry: we're talking about a package we don't control here. If somebody comes to FreeBSD from another system and X doesn't work the way he expects, he'll blame FreeBSD, not X. Disclosure: I'm unhappy that after upgrading my laptop yesterday, I found I couldn't run `x2x', Because of this issue? and had to restart my X session to remedy the problem. At least you knew what the problem was. Greg -- 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: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday, 23 April 2002 at 10:09:51 +0200, Jochem Kossen wrote: On Tuesday 23 April 2002 05:46, Greg 'groggy' Lehey wrote: On Monday, 22 April 2002 at 19:53:06 -0700, Jordan Hubbard wrote: That fix relies on the extensive PAM updates in -CURRENT however; in -STABLE it can probably be similarly replicated via appropriate tweaking of sshd (?). Why not fix it in stable by the very simple tweaking of the ChallengeResponseAuthentication to no in the sshd config file we ship Trust me, this question is going to come up a _lot_ for us otherwise. :( I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? How do I know which man page to read? If I did that for everything that happened, I wouldn't get any work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. They'll just say that it's broken and wander off again. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to be able to use it too. I'd suggest that we do the following: 1. Give the user the choice of these additional features at installation time. Recommend the procedures, but explain that you need to understand the differences. 2. Document these things very well. Both this ssh change and the X without TCP change are confusing. If three core team members were surprised, it's going to surprise the end user a whole lot more. We should at least have had a HEADS UP, and we probably need a security policy document with the distributions. I'd agree with option 2. Except that people trying to use X with tcp connections probably won't look in the security policy document for a solution. Correct. That's why I think option 1 is preferable. In the case of the X patch, i'd add it to the release notes AND the security policy document, since - i think - few people will look in the security policy document for such a problem. I think it shouldn't happen at all unless people agree to it. I do have to say you're the first one I see who complains about this... Maybe the others have given up. But since we're on the subject, why? What's so insecure about X TCP connections? Until you explicitly allow connections, the only system that can open the server is the local system. -- 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: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday, 23 April 2002 at 12:06:01 +0200, Jochem Kossen wrote: On Tuesday 23 April 2002 11:04, you wrote: [...] I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. *shrug* I was the one who sent in the patch. It was added some time around 2001/10/26 to the XFree86-4 megaport. When the metaport was created, the patch was incorporated too. A simple 'man startx' should have cleared your mind: Well, yes. But I've been using X for 11 years. Why should I have to read the man page to find changes? Because things evolve? :) Not a good reason. If they evolve, the evolution should be more clearly documented. How do I know which man page to read? You start X with startx, seems obvious to me. The disabling of tcp connections only applies to startx I don't stay with startx. Next I go to xinit, then to Xwrapper, then to X. All of these work fine. When I try to start an xterm, nothing happens. So I read the haystack of man pages for all these programs looking for a possible needle? That's 4314 lines of man pages (Xwrapper doesn't have a man page, so Murphy says that it's probably in Xwrapper). Based on prior experience, startx would be the last place I would look. In fact, I suspected a networking problem. If I did that for everything that happened, I wouldn't get any work done. And you can bet your bottom dollar that somebody coming from another UNIX variant and trying out FreeBSD won't do so. OK, then i suggest we mention it in the handbook, the security policy document, the manpage AND the release notes :) You've heard my suggestions. They'll just say that it's broken and wander off again. I note you don't comment on this one. In the case of the X patch, i'd add it to the release notes AND the security policy document, since - i think - few people will look in the security policy document for such a problem. I think it shouldn't happen at all unless people agree to it. 3 people did, 0 people did not...read below So only 3 people use X? Get real. You just haven't heard any objections up to now. I found out about this several weeks ago, but I didn't complain because I was expecting replies with the perspective you're showing. I do have to say you're the first one I see who complains about this... Maybe the others have given up. LOL THIS IS NO LAUGHING MATTER. It's this kind of change which is going to stop people from using FreeBSD. But since we're on the subject, why? What's so insecure about X TCP connections? Until you explicitly allow connections, the only system that can open the server is the local system. For the simple reason I don't like useless open ports on my system. I don't use it, _most_ other people don't use it, so i sent in a patch. Fine, I'm not telling you how to run your system. I don't want you telling me how to run my network. I note that you still haven't given a good technical reason for it. Of course, it was only discussed on the ports@ mailinglist, but it didn't seem like such a big deal to me or apparently the others... That doesn't help end users. We have a user community out there. Greg -- 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: More about security, X, rc.conf and changing defaults.
On Tuesday, 23 April 2002 at 16:35:55 -0400, Daniel Eischen wrote: On Tue, 23 Apr 2002, Frank Mayhar wrote: Terry Lambert wrote: FWIW: I wouldn't object to a firewall rule that disallowed remote TCP connections to the X server by default, if the firewall is enabled. I think we already have this... Yep, I agree, and whether or not it's in the distributed rc.firewall, I have the ports blocked in my hand-tuned version. As to Stijn's remarks, he is putting up a strawman at best. If a person runs X, it should be their responsibility to make sure that it's secure. Just like if they ran Windows or any other software with potential security holes. X is plastered with warnings as it is, why do we need to cripple a function it supports? Stijn, if it opens up a hole in your network, that's _your_ problem, not mine. There are many other ways to secure your network than by turning off tcp connections by default in the X server. Hey, I'm not objecting to adding the capability, I'm just objecting to the fact that it was imposed upon everyone else by fiat and (worse) without warning. And before people start saying again that this only affects a port and is irrelevant to the operating system itself, this is one symptom of what I see as a worsening problem. I agree also. Remember what has been stated before, Tools, not Policy. If we want to disable this by default, then there should be a customary knob _where people expect/can see it_. And if we are lacking the mechanism to do it, then the change should wait until it is present. It shouldn't be hacked into an unexpected place. Agreed entirely. I would like to see this backed out. I think it would be reasonable to fix it by tying it to the securelevel. Greg -- 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: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Tuesday, 23 April 2002 at 21:38:38 -0400, Robert Watson wrote: On Wed, 24 Apr 2002, Greg 'groggy' Lehey wrote: A more conservative default configuration results in a material improvement in system security. *snip* By snipping here, you removed reference to the fact that this was a general discussion of direction and policy, rather than specifically to do with X11, which provides an answer to a number of your questions. Sorry, I wasn't trying to obfuscate anything. I was just trying to limit the message to a manageable length. It didn't come across too well, though. - The feature does/does not have more secure alternatives accepted by the broader community. The broader community hasn't been consulted here. Not entirely clear, but worth discussing. Well, I see the broader community as the users. Now it's true that they don't have that much of a say, but what I'm seeing here is that very few people get to make these decisions. Security by obscurity does not refer to the act of selecting a conservative security policy, Don't get hung up on terminology. If you can't use terminology properly, we'll have a lot of trouble holding a useful conversation. In this particular case, the subject line was meant ironically and was mainly intended to catch people's eyes. Until you mentioned it, it didn't occur in the text. I'm more interested in the general issue here, since you made the general assertion that there was a problem that stretched beyond this one issue. Well, we saw the ssh problem as well; that's more than one. We also see things like rsh and rlogin die, maybe due to lack of love. I'm sure there are many more, some of which I have seen and accepted, others which I have seen and couldn't be bothered to complain, and others again that I haven't seen and that may or may not bite me in the future. The issue here is that the choice shouldn't be left to the individual if we're working as a team. I'm happy to entertain the idea that we discuss this specific issue in more detail. In particular, the decision to not bind the X11 port might take into account this particular implementation (XFree86), and whether we can make this setting more accessible to the administrator (i.e., something that could be mechanically twiddled, rather than through manual editing of scripts...) Well, what about checking securelevel before setting --nolisten-tcp? I think the issue here is that individuals make this kind of decision. We need a broader consensus for this kind of change. As Jochem points out, only 3 people were involved in the decision, all of them people with security profiles which weren't affected by this change. For something like X11, we need a freebsd-x11 mailing list. Or maybe freebsd-xfree86. For most other large third party applications, we either have a single authoritative maintainer, or a mailing list. For example, both Gnome and KDE have these. No, that's only part of the issue, though it's an important one. I've had complaints from Apache people that we're not communicating back enough, for example. My notion of ease of use would be dependent on the securelevel. I run a network which is heavily firewalled (has to be: I have Linux boxes here too :-), and within which the security is very lax. I have yet to see any proof that this is a problem. Sure, set the machine up for secure operation by default, and issue dire warnings about relaxing security, but don't try to know better than the user. Securelevels are a specific security model that doesn't relate to this at all. Arguably, securelevels contribute more to shoot footing than about any other feature we provide easy access to with sysinstall. I'd rather leave securelevels as they are: a model restricting root privilege, and not tangle them into any more features than necessary. Securelevels are *not* a good model for security management, although they might act as a tool in a general security posture. The security profile concept has provided for similar confusion and problems -- witness NFS breaking between our platform and others because someone selected the default (cancel) rather than moderate as their security profile, but not to other platforms. Tying a bunch of unrelated security features together rather than just itemizing them causes a lot of confusion, especially when the security feature menus conflict with other menus that toggle the same features (enabling NFS specifically vs. having it turned back off again by sysinstall for a security profile). If we can expose this feature via rc.conf, just make it a seperate rc.conf entry and twiddle it off of the security configuration manu in sysinstall. Is that something we can do easily? I think the issue is POLA. Sure, we can put in individual knobs to twiddle, but who will do that? I thought that securelevel would have been a suitable solution to say I want approximately *this* much security
Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Monday, 22 April 2002 at 19:53:06 -0700, Jordan Hubbard wrote: That fix relies on the extensive PAM updates in -CURRENT however; in -STABLE it can probably be similarly replicated via appropriate tweaking of sshd (?). Why not fix it in stable by the very simple tweaking of the ChallengeResponseAuthentication to no in the sshd config file we ship Trust me, this question is going to come up a _lot_ for us otherwise. :( I've been noticing a continuing trend for more and more safe configurations the default. I spent half a day recently trying to find why I could no longer open windows on my X display, only to discover that somebody had turned off tcp connections by default. I have a problem with this, and as you imply, so will a lot of other people. As a result of this sort of thing, people trying to migrate from other systems will probably just give up. I certainly would have. While it's a laudable aim to have a secure system, you have to be able to use it too. I'd suggest that we do the following: 1. Give the user the choice of these additional features at installation time. Recommend the procedures, but explain that you need to understand the differences. 2. Document these things very well. Both this ssh change and the X without TCP change are confusing. If three core team members were surprised, it's going to surprise the end user a whole lot more. We should at least have had a HEADS UP, and we probably need a security policy document with the distributions. Greg -- 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: Entering DDB from X11
On Saturday, 20 April 2002 at 15:33:15 -0600, Lyndon Nerenberg wrote: I've been having problems with a machine locking up while running X11, and the usual console break sequence doesn't work. Is there a way to break to the kernel debugger from X11? No. Or am I stuck with wiring up a serial port console? Currently yes. Greg -- 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: Is a debug kernel slower than a non-debug one ?
On Saturday, 6 April 2002 at 23:40:45 -0800, Doug White wrote: On Sat, 6 Apr 2002, Greg 'groggy' Lehey wrote: Note that the kernel binary with debugging symbols is left in /sys/compile/MYKERNEL/kernel.debug while the actual kernel is stripped before installation into /kernel. If the debugging kernel was actually loaded it would be gigantic :) No, since the transition to ELF, none of the debugging information gets loaded into core. Try it. Huh? I know that since 3.X, the kernel with debugging symbols is NOT loaded into the actual installed, running kernel. However, you can specify a debugging kernel to kgdb as the exec-file and it will load properly. Sure, but that wasn't the question. Greg -- 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: Is a debug kernel slower than a non-debug one ?
On Friday, 5 April 2002 at 14:18:38 -0800, Doug White wrote: On Fri, 5 Apr 2002, Alessandro de Manzano wrote: On Fri, Apr 05, 2002 at 12:00:05PM -0800, Alfred Perlstein wrote: Wow, thanks for the super-fast answer! :)) on my production servers' kernel so in the very rare case of crash I'll got a crash dump ( I'ld use also options DDB_UNATTENDED) and could immediately have a backtrace report. ..Am I crazy ? :-)) I don't think you'll notice a difference for most stuff, this is how does the -g option (GCC option I guess) disable the -O optimizing option ? If -g simply attach the symbols and similar debug info to the executable I guess the kernel should not be slower, but I don't know GCC very well... Note that the kernel binary with debugging symbols is left in /sys/compile/MYKERNEL/kernel.debug while the actual kernel is stripped before installation into /kernel. If the debugging kernel was actually loaded it would be gigantic :) No, since the transition to ELF, none of the debugging information gets loaded into core. Try it. This is all detailed in the Handbook section on kernel debugging, btw. Hmm, that needs to be fixed, then. Greg -- 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
