Re: Clustering FreeBSD
Jamie Heckford [EMAIL PROTECTED] writes: In all honesty, I am just looking for something to play with and see how fast FreeBSD can go. I'd say about 2.8 m/s/s, given sufficient height. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clustering FreeBSD
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Jamie Heckford [EMAIL PROTECTED] writes: In all honesty, I am just looking for something to play with and see how fast FreeBSD can go. I'd say about 2.8 m/s/s, given sufficient height. Doh! I mean 9.8 m/s/s, of course. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clustering FreeBSD
"Koster, K.J." [EMAIL PROTECTED] writes: The terminal velocity of a PC case is probably a lot lower than the velocity of an outer edge of a 1 RPM drive. Hmm. That would make a FreeBSD cluster quite useful as a garden shredder, even with lower disc rotation speeds I'd imagine. Fun Things To Do With Disks #9,187: Take a powered-up disk out of a hot-swap storage array and experiment with the gyro effect while the disk spins down in your hands. Higher RPMs give better results; try one of the 'cudas from that E10K in the corner... "if you do it quickly, nobody will notice" DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
Gordon Tetlow [EMAIL PROTECTED] writes: If you are using apache (who isn't?), I highly suggest you look into using suexec. That way bad CGI programming is offloaded to the customer and not to your system. suexec has many weaknesses - amongst other problems, it does not set resource limits; nor does it chroot as far as I recall. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
Tony Finch [EMAIL PROTECTED] writes: Apache itself has support for setting resource limits, although I agree that in many cases you may want them to be different between the httpd and the CGIs. You most emphatically do not want to do that. You want the CGI to run with its owner's resource limits. I expect chrooting was left out because people who have the wit to set up a chroot are capable of adding a couple of lines to a C program. Said program has a big fat warning at the top that says something like "do not ever change this program, you'll only screw it up"... I'm tempted to reply "not much more than it already is". Eivind and I rewrote it for our previous employer, but the mod is part of a large chunk of proprietary code, unfortunately. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
Matt Dillon [EMAIL PROTECTED] writes: The real problem here is the CGI script / server-side design allowing the breakin in the first place. That's not a fixable problem when the customer is meant to provide his own scripts. I've worked on such a scenario before; we managed to chroot the scripts so we're reasonably confident that they can't do much harm except to themselves. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: startx /dev/mem problem
Chris Stenton [EMAIL PROTECTED] writes: Fatal server error: xf86OpenConsole: Server must be suid root This is your clue. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: startx /dev/mem problem
"Crist J. Clark" [EMAIL PROTECTED] writes: On Sat, Jan 20, 2001 at 01:51:43AM +0100, Dag-Erling Smorgrav wrote: Chris Stenton [EMAIL PROTECTED] writes: Fatal server error: xf86OpenConsole: Server must be suid root This is your clue. He might also be running at elevated securelevel. He said he wasn't. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: linux_connect() is broken
Adrian Chadd [EMAIL PROTECTED] writes: * inside a syscall, if I return (value); what happens? errno gets set to that value, and if it's non-zero, the userland syscall code returns -1 to the caller. * inside a syscall, if I set p-p_retval[0] to something, and then return (value); what happens ? If the value you return is non-zero, see above. If it's zero, the userland syscall code returns p-p_retval[0] to the caller. * Does this logic also apply to the Linux syscall stuff in the kernel? I think so. Marcel would be better placed to answer that. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Securelevel idea
"Giovanni P. Tirloni" [EMAIL PROTECTED] writes: I was thinking about securelevels this afternoon and my brain came up with an idea: what about if we could set fine-grained securelevels? Like, each securelevel could have its own set of prohibitons and that could only be changed setting some option in the kernel and compiling a new one. Congratulations, you just invented capabilities! :) http://www.trustedbsd.org/ DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New rc.d init script roadmap
Gordon Tetlow [EMAIL PROTECTED] writes: M1 (Patch included) Setup infrastructure Make rcorder compile Your rcorder patch is incorrect. FreeBSD lacks a prototype for fparseln(). It so happens that it doesn't make any difference on any of the platforms FreeBSD supports (because our ints and pointers are the same size), but that's no reason not to do things right. Also, I don't see the point in munging the Makefile like you do - I think we can live with having a Makefile that's slightly (and trivially) different from NetBSD's. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
Gordon Tetlow [EMAIL PROTECTED] writes: Actually, fparseln() is defined in libutil.h (per the man page). I don't have my current box available (power outage at home), but if you could look over it, it should work. Ah, that's right - I couldn't find the right header, I should have simply looked at the libutil Makefile. Thanks! DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: truss vs ktrace
Arun Sharma [EMAIL PROTECTED] writes: Another advantage of truss is that the output is online and interactive. ktrace requires you to use kdump to view the trace. I certainly wouldn't call truss interactive. As for online, see the -l command-line option to kdump. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: truss vs ktrace
Robert Watson [EMAIL PROTECTED] writes: There are a fair number of differences, but from my perspective, one of the primary ones is that truss relies on procfs, Truss could be easily be rewritten to use ptrace() instead of procfs. It'd be a lot slower though, because ptrace() can only return one int at a time from process memory whereas with /proc/pid/mem you can read as much as you want in one go. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
John Baldwin [EMAIL PROTECTED] writes: Huh? Int on alpha is 32, and pointer is 64. I thought we were ILP64 on 64-bit archs, but you're right. And I ought to know better... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New rc.d init script roadmap
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Your rcorder patch is incorrect.
Here's a correct patch. Does anybody mind if I commit this and
connect rcorder(8) to the build?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: Makefile
===
RCS file: /home/ncvs/src/sbin/rcorder/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile 16 Jun 2001 07:16:14 - 1.1.1.1
+++ Makefile 18 Oct 2001 19:44:57 -
@@ -3,11 +3,12 @@
PROG= rcorder
SRCS= ealloc.c hash.c rcorder.c
MAN= rcorder.8
+WARNS?= 2
LDADD+= -lutil
DPADD+= ${LIBUTIL}
# XXX hack for make's hash.[ch]
-CPPFLAGS+= -DORDER
+CFLAGS+= -DORDER
.include bsd.prog.mk
Index: rcorder.c
===
RCS file: /home/ncvs/src/sbin/rcorder/rcorder.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 rcorder.c
--- rcorder.c 16 Jun 2001 07:16:14 - 1.1.1.1
+++ rcorder.c 18 Oct 2001 19:45:27 -
@@ -41,7 +41,11 @@
#include stdlib.h
#include string.h
#include unistd.h
+#if defined(__NetBSD__)
#include util.h
+#else
+char *fparseln(FILE *, size_t *, size_t *, const char[3], int);
+#endif
#include ealloc.h
#include sprite.h
Re: buildworld breakage during make depend at usr.bin/kdump
Eugene L. Vorokov [EMAIL PROTECTED] writes: Uhmz ? Your shell is broken. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bugmeister discussion list
Doug Barton [EMAIL PROTECTED] writes: On 22 Nov 2001, Dag-Erling Smorgrav wrote: I've set up a [EMAIL PROTECTED] mailing list Any reason this can't/shouldn't be a freebsd.org mailing list? Mostly because setting up a freebsd.org mailing list takes time and I wasn't willing to wait. There will eventually be a bugbusters@ list once I get a bugbuster team organized. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Bugmeister discussion list
[apologies to those who receive multiple copies of this message] I've set up a [EMAIL PROTECTED] mailing list with the following charter: Discussions pertaining to the FreeBSD PR system. The purpose of this list is to serve as an informal forum for discussing policies and mechanisms for PR handling in the context of the FreeBSD Project. To subscribe, send the usual magic incantations to [EMAIL PROTECTED] DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Bugmeister discussion list
Gary Jennejohn [EMAIL PROTECTED] writes: This seems like a fatal name for the list considering what buggers means. I know perfectly well what it means. I did say the list was informal, didn't I? :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Unix Philosophers Please!
Nicpon, John [EMAIL PROTECTED] writes: Please specifically define where data goes that is sent to /dev/null It goes into a special data sink in the CPU where it is converted to heat which is vented through the heatsink / fan assembly. This is why CPU cooling is increasingly important; as people get used to faster processors, they become careless with their data and more and more of it ends up in /dev/null, overheating their CPUs. If you delete /dev/null (which effectively disables the CPU data sink) your CPU may run cooler but your system will quickly become constipated with all that excess data and start to behave erratically. If you have a fast network connection you can cool down your CPU by reading data out of /dev/random and sending it off somewhere; however you run the risk of overheating your network connection and / or angering your ISP, as most of the data will end up getting converted to heat by their equipment, but they generally have good cooling, so if you don't overdo it you should be OK. I hope this answers your question. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: buildworld breakage during make depend at usr.bin/kdump
Guido van Rooij [EMAIL PROTECTED] writes: May I aks which shell you are using? Zsh. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Unix Philosophers Please!
Bernd Walter [EMAIL PROTECTED] writes: In short: The data is tranfered into the kernel and dropped there. The data is never transferred into the kernel. There is no copyin() or uiomove() there. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: forwarding
Martin Vana [EMAIL PROTECTED] writes: The problem is when I try to retrive any files from users. Than DC tryies to establish direct connection to user on ports from 410-415. How could I somehow 'catch' this request (SYN_SENT foo.foobar.com 41x) and forward it through ssh tunnel and back? You can't. Don't limit yourself to just one box, I also have another FreeBsd machine ready to serve. Is the other box outside the firewall? In that case, set up PPP on both boxen (see /usr/share/examples/ppp/ppp.conf.sample) and run PPP over SSH. On the inside box, set up a single static route to the outside box and let PPP take care of the default route. The outside box should run natd or ipnat unless you have a spare IP address you can use for the PPP link. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: My contributions to the close a PR campaign
Seth Kingsley [EMAIL PROTECTED] writes: Why not remove it after using it to restore the mixer state? It would only exist to survive a reboot. You'd have to reset everything manually after a crash. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: what is PSEUDOFS?
Hiten Pandya [EMAIL PROTECTED] writes: i know what DEVFS is... after the lecture at the BSDCon 2001 Europe by phk Well, the author of pseudofs was there too, and did mention it in his lightning talk right before Jordan's MacOS X presentation. You could have asked him there :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New vhost bugs.FreeBSD.org
Maxime Henrion [EMAIL PROTECTED] writes: The recently added cvsweb.FreeBSD.org vhost makes me think we could also have one pointing to the PR database (/cgi/query-pr-summary.cgi), for example, bugs.FreeBSD.org as the subject of this mail suggests. Yes, please. DES (Bugmeister) -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Junior Kernel hacker task: Floppy driver mode handling.
Poul-Henning Kamp [EMAIL PROTECTED] writes: There exists a patch for adding a mode to our floppy driver to add DEC RX50 media handling. Clearly a job for Jessem, don't you think? :) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: New feutures...........
Rafter Man [EMAIL PROTECTED] writes: 2. I hope that in the furture the FreeBSD developers will rewrite the system in C++. You need to have your head examined. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc bug? Openoffice port impossibel to compile on 4.8
Wes Peters [EMAIL PROTECTED] writes:
GCC 3.2 is broken by design. It insists, amongst other stupidities, on
type-checking arguments using old style declarations like:
int foo(bar)
char *bar;
{}
rendering most UNIX software from before 1996 uncompilable.
have you tried -traditional?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc bug? Openoffice port impossibel to compile on 4.8
Wes Peters [EMAIL PROTECTED] writes: On Thursday 29 May 2003 00:12, Dag-Erling Smorgrav wrote: May I remind you that KR-style declarations have been deprecated for the last 14 years? Funny, the last time I looked at a C language specification they were still supported. 6.11.5 Function definitions [#1] The use of function definitions with separate parameter identifier and declaration lists (not prototype-format parameter type and identifier declarators) is an obsolescent feature. and obsolescent feature is defined as follows in the introduction: [#2] Certain features are obsolescent, which means that they may be considered for withdrawal in future revisions of this International Standard. They are retained because of their widespread use, but their use in new implementations (for implementation features) or new programs (for language [6.11] or library features [7.26]) is discouraged. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc bug? Openoffice port impossibel to compile on 4.8
Valentin Nechayev [EMAIL PROTECTED] writes: Essential words are understriked. I can't imagine how it can be read as unsupported. I didn't use the word unsupported, I said deprecated. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kvm questions
Vlad GALU [EMAIL PROTECTED] writes: Hello. I am trying to write a monitoring program which makes use of the kvm interface. procfs is significantly less evil, if you can get the information you require from it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kern/40003: Panic on boot w/4.6-stable
Charles Sprickman [EMAIL PROTECTED] writes:
(kgdb) up 11
#11 0xc013e8a5 in ad_attach (atadev=0xc075b650) at ../../dev/ata/ata-disk.c:124
124 adp-heads = atadev-param-heads;
(kgdb) p adp
$2 = (struct ad_softc *) 0x68c040
(kgdb) p atadev
$3 = (struct ata_device *) 0xc075b650
(kgdb) p *adp
Cannot access memory at address 0x68c040.
(kgdb) p *atadev
$4 = {channel = 0xc075b600, unit = 16, name = 0xc04503b0 ad1, param = 0x0,
driver = 0x0, flags = 0, mode = 0, cmd = 0, result = 0x0}
ad_attach() is trying to dereference atadev-param, which is NULL.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Accessing memory below 1 MB
[EMAIL PROTECTED] writes:
I'm writing some graphics code (just for fun) and I need legal access to
the memory addresses below 1 mb.
You can't access the framebuffer directly in FreeBSD like you can in
DOS. Take a look at libvgl ('man vgl').
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Increasing KVM
Ian Campbell [EMAIL PROTECTED] writes: How exactly would I go about increasing KVM? Read the FAQ. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB support for new HP printers?
John Nielsen [EMAIL PROTECTED] writes: Hi, John. The LaserJet 1200 advertises several alternate settings for the printer-class interface: 7/1/3 (for IEEE 1284.4 packets, the new and different USB interface you mentioned), 7/1/2 (bidirectional raw print data), and 7/1/1 (unidirectional raw print data). If you can somehow convince the ulpt driver to bind to 7/1/2 or 7/1/1 rather than just blindly binding to the first alternate setting it finds, then that should be all you need. Interesting. I wonder if the same applies to the OfficeJet. I have a d145, and while FreeBSD recognizes it just fine, and attaches it as a ulpt device, it fails to print (the process that tries to write to /dev/ulpt0 just hangs). I'll see if I can figure out a way to force the ulpt driver to bind to 7/1/2. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: USB support for new HP printers?
The attached patch allows me to print to my HP OfficeJet by making
ulpt0 use the bidirectional interface (7/1/2) instead of the IEEE1284
interface (7/1/3). I haven't had time to set up CUPS yet, but simply
catting a text file do /dev/ulpt0 works fine, while previously it
would just hang.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
Index: sys/dev/usb/ulpt.c
===
RCS file: /home/ncvs/src/sys/dev/usb/ulpt.c,v
retrieving revision 1.50
diff -u -r1.50 ulpt.c
--- sys/dev/usb/ulpt.c 30 Oct 2002 01:18:58 - 1.50
+++ sys/dev/usb/ulpt.c 4 Dec 2002 23:33:39 -
@@ -236,8 +236,7 @@
id-bInterfaceNumber == ifcd-bInterfaceNumber) {
if (id-bInterfaceClass == UICLASS_PRINTER
id-bInterfaceSubClass == UISUBCLASS_PRINTER
- (id-bInterfaceProtocol == UIPROTO_PRINTER_BI ||
- id-bInterfaceProtocol == UIPROTO_PRINTER_1284))
+ id-bInterfaceProtocol == UIPROTO_PRINTER_BI)
goto found;
altno++;
}
Re: End-Of-Life announcement for M-Systems DiskOnChip driver(fla).
David Yeske [EMAIL PROTECTED] writes: I still use this. Users will not suddenly quit using hardware that works, they will start using a different OS that works with it, or they will be stuck trying to continue to support an old version of FreeBSD because it works with it. Read the announcement again. FreeBSD 5.x will still have DoC support, which means you have at least two years to grow tired of it before we stop putting out 5.x releases. By that time you will hopefully have realised it is a dead-end technology and switched to something that works. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: replacing GNU grep with UNIX grep.
Sergey Babkin [EMAIL PROTECTED] writes: Also the GNU grep has a lot more options, the most interesting of them being -r. Unfortunately, GNU grep's -r option is broken (it does not handle symnlinks correctly). Try textproc/freegrep from ports instead. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
Doug Barton [EMAIL PROTECTED] writes: On Tue, 28 Jan 2003, Garance A Drosihn wrote: Well for one thing, if a given file has a lot of changes, then I would like mergemaster to skip over the initial one-line change that only tells me how some comment now has a new version-number in it. This is an oft-requested feature, but I'm not sure how best to implement it. Look up the -I option in the diff(1) man page. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Modifying mergemaster behavior
Doug Barton [EMAIL PROTECTED] writes: I didn't say I don't know HOW to implement it, I said I didn't know how BEST to implement it. You snipped the part of my e-mail where I explained the issues. I don't see the problem, you don't need to run diff twice... no more than you already do (any reason why you don't use cmp instead of diff on line 815?) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Help with understanding process state, context switching andsignals
Andrey Simonenko [EMAIL PROTECTED] writes: In short: I need to stop (suspend) some process from the kernel, when that process is in user mode and get information about its general-purpose registers, its VM structures, etc. Have you looked at ptrace(2)? That's what gdb(1) uses. You can get additional information about memory maps etc. from procfs. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OpenPAM and OSVERSION
Sergey Matveychuk [EMAIL PROTECTED] writes: What is OSVERSION num right after OpenPAM implemented? What problem are you trying to solve? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OpenPAM and OSVERSION
Sergey Matveychuk [EMAIL PROTECTED] writes: What is OSVERSION num right after OpenPAM implemented? What problem are you trying to solve? security/pam-* ports. I'v fiexed pam-mysql for this time. It's works for me. I'm working for PR. If you've fixed it in a way which requires knowing whether the system runs Linux-PAM or OpenPAM, you've fixed it wrong. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OpenPAM and OSVERSION
Sergey Matveychuk [EMAIL PROTECTED] writes: If you've fixed it in a way which requires knowing whether the system runs Linux-PAM or OpenPAM, you've fixed it wrong. OK. Why? Because most PAM problems in ports are bugs in the ports themselves, which Linux-PAM just happens to tolerate and OpenPAM doesn't. In other words, it should be possible to find a solution to the problem which works equally well for Linux-PAM and OpenPAM, without the need to know which is which. And as a last resort, you can make OpenPAM- specific code conditional on the _OPENPAM preprocessor symbol. What fix will be a right one? I can't tell you unless you show me what you believe needs fixing. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OpenPAM and OSVERSION
Sergey Matveychuk [EMAIL PROTECTED] writes: What a right way escape from PAM_CONV_AGAIN/PAM_TRY_AGAIN and relate code from LINUX_PAM? Shoot the module author for using it, and Andrew Morgan (Linux-PAM author) for inventing it. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Some security questions.
Julian Elischer [EMAIL PROTECTED] writes: 1/ Command logging. We're thinking that a hacked version of the shell that logs commands may do what they want, but personally I think that if you are going to log things then you really want to PROPERLY do it, and log the EXEC commands along with the arguments. (sadmin et al. doesn't give arguments, and neither does ktrace) Yes, we can do that in the sense that it can be implemented if there's a demand for it, but I don't think any existing code can do it. 2/ they want to disable a login if it fails 'n' sequential logins anywhere in the system. i.e. 2 on one machine followed by another on another machine. Yes we can do that with a smart PAM module. I can immagine using pam_radius, and hacking a radius server to track login fails.. Anyone have any better ideas? Maybe a pam_module specially written? (h) PAM has a mechanism which allows for arbitrary named objects to be stored for the duration of a PAM transaction, along with a destructor which is called when the object is released (either explicitly or when the transaction ends). You could write a PAM module which stores an object in the authenticate phase, then modifies its contents in the setcred phase (which only occurs if authentication was successful). The destructor would register success or failure in a database depending on whether the object was modified before release. The exact nature of that database is not important. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: dynamic hints
Peter Wemm [EMAIL PROTECTED] writes: Yes, sort-of. kenv(8) can change the strings. But I suspect it is too late for something like isa since I think it would have done a pass at boot to create the attachment nodes. But as configuration knobs for drivers that want to examine a string directly via getenv() etc, those would not be too late. It wouldn't be too late for loadable modules... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: debugging a repeating panic that does not produce a dump
Mike Tancsa [EMAIL PROTECTED] writes: I am seeing a repeatable panic with a 4.x SMP machine (not when in uni mode). It never produces a crash dump, but always panics when periodic runs. Hmm, it doesn't even seem to *try* to dump... are you sure you have configured a dump device? instruction pointer = 0x8:0xc0174830 This is the address of the instruction which caused the fault. You can run nm(1) on your kernel to find out where in the kernel that is, e.g.: # nm /kernel | grep \^c0174 | sort this should give you a list of maybe a dozen symbols; the one you want is the last one in the list that has a lower address than c0174830. How do you build your kernels - 'make buildkernel' or manually? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: debugging a repeating panic that does not produce a dump
Mike Tancsa [EMAIL PROTECTED] writes:
ns4# nm /kernel | grep \^c0174 | sort
[...]
c01747d4 T makedev
c01748f4 T freedev
This is it (makedev)
Does this actually show the location ?
ns4# gdb -k kernel.debug
[...]
(kgdb) list *0xc0174830
0xc0174830 is in makedev (/usr/src/sys/kern/kern_conf.c:208).
203 if (x == umajor(NOUDEV) y == uminor(NOUDEV))
204 Debugger(makedev of NOUDEV);
205 udev = (x 8) | y;
206 hash = udev % DEVT_HASH;
207 LIST_FOREACH(si, dev_hash[hash], si_hash) {
208 if (si-si_udev == udev)
209 return (si);
210 }
211 if (stashed = DEVT_STASH) {
212 MALLOC(si, struct specinfo *, sizeof(*si), M_DEVT,
(kgdb)
Yep. Looks like si is garbage:
fault virtual address = 0x211e6d36
is most likely the value of si at the time of the crash. It's nowhere
near kernel memory (which starts at 0xc000).
If / when you get a dump, show me the backtrace and the value of x, y
and udev (as reported by gdb operating on the recovered core)
How do you build your kernels - 'make buildkernel' or manually?
Always make buildkernel. I have a debug kernel built as well
(makeoptions DEBUG=-g)
That's what I wanted to know.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: debugging a repeating panic that does not produce a dump
Mike Tancsa [EMAIL PROTECTED] writes: Thank you very much, I will do so as soon as I get the dump. BTW, could the act of giving the wrong params to dumpon cause the crash ? No, it wouldn't. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
[EMAIL PROTECTED] writes: Well, I'm right in principle but wrong in current practice, at the very least make it: #define arc4random31() (arc4random() RAND_MAX) or rather #define arc4random31() (arc4random() % (RAND_MAX + 1)) to avoid relying on RAND_MAX being one less than a power of two. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: arc4random() range
Peter Jeremy [EMAIL PROTECTED] writes: In any case, doesn't the name imply that it's 31-bits... Yes, it's a bad name. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: debugging a repeating panic that does not produce a dump
Mike Tancsa [EMAIL PROTECTED] writes: Fatal trap 12: page fault while in kernel mode mp_lock = 0002; cpuid = 0; lapic.id = 0100 fault virtual address = 0xc6efa8e8 Hmm, different fault address this time. (kgdb) up 6 #6 0xc0174830 in makedev (x=28, y=160) at /usr/src/sys/kern/kern_conf.c:207 These numbers look perfectly valid (cuaia0). The only explanation I can think of is some kind of race, or some kind of corruption. Hopefully somebody more clued than myself will be able to figure it out. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: debugging a repeating panic that does not produce a dump
Mike Tancsa [EMAIL PROTECTED] writes: It only happens when periodic runs, but it on occasion skips a day. Eg. yesterday it did not do it. It only started happening post Jan28th. I can brutalize the server with repeated buildworlds (-j2 through 8) and it is always successful. Its only on periodic that it dies and find is always the process running. Its only with SMP as well on this 'oldish' machine Hmm, it would be great to know what process was running when it crashed. Unfortunately, I don't know how to do that post-KSE... DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: booting from Promise tx2000: FIXED
Len Conrad [EMAIL PROTECTED] writes: while waiting for Soeren Schmidt to get the Promise SX4000 driver done! I was under the impression that the SX4000 and SX6000 were already supported? I know that phk has an SX6000 which he says works fine. OTOH, it's possible that this hasn't percolated down to -STABLE yet. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 3 IDE devices on Promise card + FreeBSD == not possible?
Pete [EMAIL PROTECTED] writes: atacontrol create mirror ad6 ad7 This is starting to _really_ confuse me. Does FreeBSD have two software RAID systems? Yes (vinum and raidframe) Is there something built into the ATA controller drivers that can do software RAID too? It looks that way from that atacontrol and ata man pages. No, but atacontrol knows how to configure hardware RAID controllers such as your Promise FastTrack. Where does Vinum fit in here or is Vinum extraneous now? Vinum is a volume manager with RAID functionality. Is Vinum just a front-end to the ata system? No, it's completely device independent. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ptrace and SIGTRAP problem
Zhihui Zhang [EMAIL PROTECTED] writes: The following small program demonstrates that a parent process can write into the data space of its child by ptrace(). If the parent waits for the child to exit, there is no problem. However, if the parent does not do so, the child will get a SIGTRAP signal and core dumps. Can anyone give me a clue how this is the case? Thanks! The parent must either detach from the child, or wait for it to terminate. See ptrace(2). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ptrace and SIGTRAP problem
Zhihui Zhang [EMAIL PROTECTED] writes: - PT_CONTINUE + waitpid() works fine, the trace program prints out values. This is expected behaviour. - PT_CONTINUE alone does not work but no core-dump caused by SIGTRAP - PT_DETACH + waitpid() does not work and core-dump - PT_DETACH alone does not work and core-dump. These three cases are unexpected. I'll have to dig some more into this, but I'm afraid I won't have time until some time next week. Who is sending the SIGRAP (5) signal? execve(2) in kern_exec.c posts SIGTRAP if the process has debugging turned on (which it does as a result of PT_TRACE_ME). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Ptrace and SIGTRAP problem
Zhihui Zhang [EMAIL PROTECTED] writes: On 9 Feb 2002, Dag-Erling Smorgrav wrote: execve(2) in kern_exec.c posts SIGTRAP if the process has debugging turned on (which it does as a result of PT_TRACE_ME). This is one time thing. It will be catched by the first wait() call in the parent process. Yes. Subsequent SIGTRAPs normally indicate that syscall tracing is enabled (see /sys/i386/i386/trap.c) but I don't think that's the case here. I'll try to figure out what's happening when I find time. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
OpenPAM Caliopsis + integration patches
OpenPAM Caliopsis and accompanying FreeBSD integration patches are now available from URL:http://openpam.sourceforge.net/. A fully patched tree is also available from the p4 depot, under //depot/user/des/pam/. Please see the release notes and change log for information about known and resolved issues. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Make's ongoing effort to get his PR's closed...
Mike Meyer [EMAIL PROTECTED] writes: In my ongoing attempt to get my PR's closed, here's the list again. They are listed roughly in the order of difficulty. Please send this to [EMAIL PROTECTED] DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: in-kernel HTTP Server for FreeBSD?
Hiten Pandya [EMAIL PROTECTED] writes: Is there any In-Kernel HTTP Server for FreeBSD, like there is kHTTPD for Linux? God forbid! Lots of hack value, sure, but not something you'd seriously consider for production use. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: in-kernel HTTP Server for FreeBSD?
Thomas Hurst [EMAIL PROTECTED] writes: Don't functions like FreeBSD's zero-copy sendfile() provide similar performance benefits without the massive security issues? sendfile() isn't zero-copy, it's just two-less-copies. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: in-kernel HTTP Server for FreeBSD?
Roy Sigurd Karlsbakk [EMAIL PROTECTED] writes: well .. So let's turn the question upside-down, and ask Is there a web server or -accelerator for FreeBSD with similar performance as with khttpd or Tux? Have you tried thttpd or boa? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: in-kernel HTTP Server for FreeBSD?
Roy Sigurd Karlsbakk [EMAIL PROTECTED] writes: sendfile() isn't zero-copy, it's just two-less-copies. zero-copy means zero copy-operations within memory To an MCSE, maybe. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: in-kernel HTTP Server for FreeBSD?
Roy Sigurd Karlsbakk [EMAIL PROTECTED] writes: sendfile() isn't zero-copy, it's just two-less-copies. zero-copy means zero copy-operations within memory To an MCSE, maybe. strange ... [...] So what would you call direct DMA from the disk controller to the network adapter? Minus-one-copy? And even in the sendfile(2) case, data sometimes *is* copied in-core to satisfy alignment requirements etc. Stop using buzzwords just because they give you a woody. (and yes, even a Dr. Scient can be mistaken. Papers don't make you smart, you know - though I wouldn't expect someone who brags about being an MCSE and MCNE to understand that) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: in-kernel HTTP Server for FreeBSD?
Roy Sigurd Karlsbakk [EMAIL PROTECTED] writes: er.. So - if you certify within a product, you'll probably become dumber? Getting an MCSE or an MCNE doesn't necessarily make one dumb - though some might ask if one couldn't find anything better to do with one's (employer's) time and money. Believing that it's worth more than the paper it's printed on, however, and bragging about it in an open-source forum, raises serious questions about one's intellectual acumen. Now, a CCNE, on the other hand... DES (neither of the above) -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Four misc. questions related to jail usage
Patrick Thomas [EMAIL PROTECTED] writes: 1. Does each jail need to have its own proc filesystem mounted? No, procfs is pretty much useless these days (except for truss). 2. Does kern.maxproc scale in a linear fashion with maxusers ? The default value for kern.maxproc is 20 + 16 * maxusers. 4. Why is it that some linux utilities, run inside a jail, get the hostname of the host machine, and not the hostname of the jail itself? It's a bug. It was fixed recently (in the last few days) in -CURRENT. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Four misc. questions related to jail usage
Patrick Thomas [EMAIL PROTECTED] writes: No, procfs is pretty much useless these days (except for truss). In 4.5, won't `ps` (and perhaps other apps) not work for people in a jail if their jail does not have a proc file system mounted in their /proc ? Only 'ps -e'. Everything else will work just fine. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU [EMAIL PROTECTED] writes: I have attached a patch for the 'rm' untility, which strips the trailing slash(es) from the path (according to Posix.2). But I think there are many other utilities which need to be patched (e.g. cp, mv). Please don't. This functionality is extremely useful. Consider this: des@des ~% mkdir foo des@des ~% touch foo/bar des@des ~% ln -s foo baz des@des ~% ls -l baz lrwxr-xr-x 1 des des 3 Apr 10 16:15 baz - foo des@des ~% ls -l baz/ total 0 -rw-r--r-- 1 des des 0 Apr 10 16:15 bar and the same scenario on Solaris: des@sex ~% mkdir foo des@sex ~% touch foo/bar des@sex ~% ln -s foo baz des@sex ~% ls -l baz lrwxrwxrwx 1 des des3 Apr 10 16:16 baz - foo/ des@sex ~% ls -l baz/ lrwxrwxrwx 1 des des3 Apr 10 16:16 baz/ - foo/ [scream and curse] des@sex ~% cd baz des@sex ~/baz% ls -l total 0 -rw--- 1 des des0 Apr 10 16:16 bar In my humble opinion, Solaris (and every other *nix) is broken in this respect, and *BSD is correct. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU [EMAIL PROTECTED] writes: On 10 Apr 2002, Dag-Erling Smorgrav wrote: In my humble opinion, Solaris (and every other *nix) is broken in this respect, and *BSD is correct. Except for OpenBDS. No NetBDS machine available, maybe some of you could try it on one as well? I don't know of any OpenBDS or NetBDS, but NetBSD has the same semantics as FreeBSD: des@rc4 ~% mkdir foo des@rc4 ~% touch foo/bar des@rc4 ~% ln -s foo baz des@rc4 ~% ls -l baz lrwxr-xr-x 1 des des 3 Apr 10 16:41 baz@ - foo des@rc4 ~% ls -l baz/ total 0 -rw-r--r-- 1 des des 0 Apr 10 16:41 bar DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: 'rm' incompatibility with Posix.2
Bogdan TARU [EMAIL PROTECTED] writes: Could you also try the NetBDS's 'rm'? If it does work like FreeBDS, than I really don't know what to believe anymore. It doesn't, actually, it removes the symlink rather than the directory it points at. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: procfs issue.
Alfred Perlstein [EMAIL PROTECTED] writes: It looks like the following delta (submitted by Tim J. Robbins) may fix it: It looks correct to me, please commit (unless John has any objections?) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: jail in 4.5-RELEASE: setrlimit() and blocked processes
John Kozubik [EMAIL PROTECTED] writes: You can solve this problem by removing the setrlimit() call in postfix, with the following patch: s/solve/work around/ The correct *solution* would be to fix setrlimit(). DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Erm, since everyone managed to HIJACK my sshd thread! ;)
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -hackers is not the appropriate forum for code review. The patch is incorrect and should be backed out. Never mind, I did it myself. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: /usr/include/netinet/in.h
Ian [EMAIL PROTECTED] writes: The general rule is including includes from includes is bad. Okay, it's time to point out that these are opinions, not rules, and differing opinions exist. POSIX disagrees with you. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Is gethostbyname2() reentrant?
Peter Haight [EMAIL PROTECTED] writes: If I link with libc_r can I use gethostbyname2() at the same time in two different threads? Use getaddrinfo() instead. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: allocating memory
Stephen Montgomery-Smith [EMAIL PROTECTED] writes:
I have access to a rather large computer (3GB of RAM) and I would like
to write a program to access most of this memory. I find that I am
unable to malloc more than about 0.5 GB of memory, even if I do it in
small increments. Now I am trying mmap, and this lets me get to about
2.5 GB of memory (again I ask for the memory in small increments). What
is it that causes these limitations?
man limits, and see MAX{DSIZ,SSIZ} in NOTES.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: kern/40003: Panic on boot w/4.6-stable
Charles Sprickman [EMAIL PROTECTED] writes: On 28 Jul 2002, Dag-Erling Smorgrav wrote: ad_attach() is trying to dereference atadev-param, which is NULL. Is there any other info I can provide? I'll drive, you steer. :) No, this is Søren's cup of tea, which is why I Cc:ed him. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
Kelly Yancey kby...@alcnet.com writes: Hmm. I sent this message a few days ago and it has been silently ignored. Should I consider that an OK to extern the get_mode_param function in vga_isa.c? Or should I take that as a mass go ahead, we're not going to commit the code anyway? :( Hmm, well, I don't like to say go ahead, we're not going to commit the code anyway, but I can't see the use of adding Mode X support - I feel that the gain in functionality is too small to justify the added complexity. You'll need to add bits to the video_info structure to describe the encoding. AFAIK, the current model can only describe linear and plane-per-channel encodings accurately, whereas Mode X uses a weird interlaced encoding. The designers of the VGA chipset ought to be taken out and shot. You'll need to hack everything that hooks into syscons but doesn't explicitly set the video mode to check for Mode X so they won't shoot themselves in the foot trying to address it as a linear mode. To summarize, it seems like a lot of trouble just to get 40 additional scanlines and square pixels on obsolete hardware - anything that doesn't support 'options VESA' was already obsolete five years ago. It's not going to make FreeBSD a better desktop OS (desktop users use X, not syscons) and its' not going to make FreeBSD a better server OS (no, a prettier splash screen does not make your server faster). OBTW, Mode Q has square pixels and linear addressing. I won't mind adding support for Mode Q :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: fsck and large file system
Mark J. Taylor mtay...@cybernet.com writes: The problem that we ran into in a system with several 130 MB RAID5 arrays is that the fsck was running out of RAM+swap. We had to add a vnode to swap to before the fsck would complete (basically added more swap space). We had to have over 100 MB swap space to fsck the 130 MB volume, and the system has 64 MB RAM. This was is 2.2.8 (haven't upgraded it yet). I *really* hope you meant 130 GB and not 130 MB :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
Kelly Yancey kby...@alcnet.com writes: What I don't get is how the memory is presented to apps using the driver. The best I could think of would be to present it a 256k linear frame buffer with the pixels in order (ie writes to consecutive pixels would result in the driver switching planes), and while that would present a consistent interface, it would be *really* slow (if it is even possible). Yes, it's possible, but it requires a page fault on *every* write to video memory. YA case of 'possible, but not practical'. (this technique has been used to simulate a linear frame buffer when using paged modes, but I haven't yet succeeded in convincing Kazu to implement it in the VESA driver and I don't have the time or know-how to do it myself) The next best thing would be to present it a 256k linear frame buffer but with each plane 64k after the previous. Applications would have to be aware of the layout (ie. know that modex modes aren't linear) because writes to consecutive memory addresses would result in changing every 4th pixel. This is the method I would assume must already be in place for the existing 320x240 mode, but I can't find it. Which means that at the moment 320x240 is useless? Yes, if it's there at all you have to switch banks manually. Really, I was thinking that this would be a neat thing to add. I could have some higher resolution video modes without needing VESA (and VM86). The VESA code is very small, and you want VM86 anyway (amongst other things, for reliable memory detection) But you make a good point in that anyone who wants graphics uses X. I guess I was thinking that maybe the additional modes would be of use should FreeBSD ever really get an equivalent to libsvga. We already have that (libvgl), though it's in deperate need of maintenance. Anyway, as you point out, then the modes are really only of use to splash screens (which is a minor feature in and of itself). So the question becomes, is there any interest in adding 6 mode tweaked modes (in addition to the existing 320x240) or should we reduce complexity and remove the 320x240 mode because surely nothing can be using it (you can only write to every 4th pixel right now). I vote for the latter. OBTW, Mode Q has square pixels and linear addressing. I won't mind adding support for Mode Q :) Mode Q? I'm not familiar with that one. Presumably a less-than-320x200 resolution? No, actually it has 1536 more pixels :) Mode Q is so named because the frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) If you have time and talent to spare and want to work on the console code, I have two suggestions for useful additions: - modify syscons so userland software can mmap the frame buffer, and whatever other modifications are necessary to make it possible for userland software to use graphics without needing write access to /dev/kmem (currently, the only way to mmap the frame buffer is to map in the correct address range from /dev/kmem) - port GGI to FreeBSD. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
Kelly Yancey kby...@alcnet.com writes: On 14 May 1999, Dag-Erling Smorgrav wrote: No, actually it has 1536 more pixels :) Mode Q is so named because the frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors) Yeah, I've seen the DOS port of snes9x use that. I don't think it has truely square pixels though since the screen has a 4:3 aspect ratio and the resolution is 1:1...the pixels should look slightly wider than they are tall. Most monitors display Mode Q with wide black margins. But it is linear :) The question is...is it worth including? I just did a quick search on the net and found the register programming information for this one (256x256x256) and another interesting linear mode (296x220x256) which has almost square pixels and a slightly higher resolution. Umm, no, 296x220 is smaller than 256x256. And if the verdict is that the extra video modes (so long as they are planar) are useful, then how about some tweaked text modes? We have support for a number of different rows, but I have some old patches (which need updating) for extending the number of text mode columns from 80 to 90. Yah. If you can make it work, I'm all for it. - port GGI to FreeBSD. I thought this had been discussed and shot down? If it has, I didn't see it :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 1GB, kvm issues.
Chuck Youse cyo...@cybersites.com writes: It's been noted on several occasions that with large ( 256MB) of RAM, one has to be careful with the configuration (NMBCLUSTERS, MAXUSERS) to prevent the box from falling over every few days due to kvm problems. It's not a problem as long as your kernel address space is large enough. The default in -CURRENT and recent versions -STABLE is 1 GB, which should be enough for most (if not all) uses. The default for 3.1-RELEASE and -STABLE up to mid-April is 256 MB. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: MB86950 Support in the works?
Kris Kirby k...@airnet.net writes: I was wondering if any adventurous individual has looked into writing a driver for the MB86950 ethernet controller. I have quite a few cards that use this chip and would be more than willing to acid-test the driver. (Ever got 1MB/s over coax? :-)) Yes, I've experienced sustained transfer rates in excess of 1 MBps on a 10Base2 network, with FreeBSD 3.1 using an SMC based Kingston EtherX (ISA PnP NE2000 clone thingamabob) in one end and a nondescript Linux box in the other end. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD, GPL, the world today.
Nik Clayton n...@nothing-going-on.demon.co.uk writes: Didn't Knuth say I've only proven TeX to be correct, I haven't tested it or some such? TeX is far too large to undergo even a partial correctness proof, much less a total correctness proof (I'm not even sure total correctness can be proven; cf. the halting problem). I seriously doubt Knuth ever considered undertaking such a task. It's quite possible, though, that he's proven partial or total correctness of some portions of it (such as frequently-used low-level routines). Correctness proofs are very time-consuming, because they can't be automated. There are experimental tools which can assist with part of the work (e.g. the partially-completed Abel project at the University of Oslo: URL:http://www.ifi.uio.no/~prover/abel/) but the hardest part of the job - finding loop and type invariants and post- and pre-conditions which the prover can use as starting points - must still be done manually. The day when a computer can prove partial correctness of a program on its own is the day when computers gain the ability to program and debug themselves - and we'll all be out of a job and out of a hobby. I could well be mis-remembering a quote about some other app. As I remember it, the quote referred to a noddy program used as an example in a paper or lecture. Knuth had proven the program to be correct, but had never actually compiled it. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: BSD, GPL, the world today.
Daniel C. Sobral d...@newsguy.com writes: Dag-Erling Smorgrav wrote: [...] but the hardest part of the job - finding loop and type invariants and post- and pre-conditions which the prover can use as starting points - must still be done manually. Things like SPIN goes a long, long way to make such proofs more viable. Take, for instance, correctness proofs of Fluke IPC subsystem. Invariants and pre- and post-conditions (aka internal documentation) must still be written by humans. The computer can prove that a subroutine fulfills its purpose, but it can't guess at that purpose. The best it can do is start with type invariants (this function receives one integer parameter, and integers range from -2^31 to 2^31-1), and use forward construction to generate a post-invariant for the function, but such machine-generated post-invariants are mostly useless. Inference rules which rely on right consequence and right-constructive axiom schemas tend to produce complicated expressions riddled with icky quantifiers (in other words, garbage - provably correct garbage, but garbage nonetheless). For a useful proof, you need either a very restrictive precondition, or a postcondition which accurately describes the intended result. The latter is preferred, since left construction is much easier to handle than right construction. As long as programs are written by humans, making human assumptions, humans will be required to document their assumptions. One other problem is proof of termination. A computerized proof system may be able to prove termination of simple loops and some cases of recursion, but anything more than that gets dangerously close to the halting problem, which is unsolvable by a deterministic computer. Ghod knows termination is hard enough to prove for humans... DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vmapbuf (was:Which O/S routines are subject to change?)
Stan Shkolny s...@osgroup.com writes: [...] (BTW, I found it very-very-VERY helpful that I did it first under NT, since NT has kernel-mode debugger :-). Oh, and FreeBSD doesn't? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: modex support (again)
Kazutaka YOKOTA yok...@zodiac.mech.utsunomiya-u.ac.jp writes: In that sense, the support for 320x240 mode-X is minimal too. The driver can set up this mode, but has no knowledge or code to write to it. It is entirely up to the userland program to update the video buffer. (And it is true that there is very little use to this mode at the moment as we haven't seen anybody using it...) I believe the video_info_t etc. structures aren't able to accurately describe how to address mode X. The graphics code in the graphical screen savers and the splash screen decoders is written in such a way that it does not care if the current mode is linear or windowed (a linear frame buffer is a windowed frame buffer with a window size large enough to hold the entire screen). Extending this code to work with mode X is not trivial; you either have to write a separate drawing function for mode X, or put so much magic in your drawing function that it will bog down to something like 3 fps. And you can't just look at your video_info_t and see that mode X is interlaced; you have to *know* that you're running in mode X and that mode X is interlaced. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
SA_{SPACE,REWIND,ERASE}_TIMEOUT
I want to convert these kernel options to sysctl variables. Where should they be inserted into the tree? I was thinking of creating a new 'cam' top-level category and put them there: cam.sa.space_timeout cam.sa.rewind_timeout cam.sa.erase_timeout DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: New one - mp3 clicks during playback
Karl Denninger k...@denninger.net writes: If the system starts taking interrupts, I get clicks, roughly consonant with the interrupts, in the output. They're solidly correlated with disk activity. Do you have IDE disks? Do they run in DMA mode? If not, switch to DMA mode. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
fetch(1) / fetch(3) patchkit available
Hey guys, I brushed the dust off a bunch of patches I had for libfetch and the fetch(1) command and made a patchkit of them (in the great tradition pioneered by messrs. Schmidt, Dillon and Yokota). Some of it is five month old patches I never got around to comitting, some of it is new code, and some of it is a complete replacement for the fetch(1) command. The code and documentation (yes, Nik, I wrote docs!) is available at URL:http://www.freebsd.org/~des/software/. As usual, comments and patches are welcome. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: fetch(1) / fetch(3) patchkit available
Sheldon Hearn sheld...@uunet.co.za writes: On 28 May 1999 10:29:44 +0200, Dag-Erling Smorgrav wrote: I brushed the dust off a bunch of patches I had for libfetch and the fetch(1) command and made a patchkit of them [...] Your mail has brought to mind a question I've never managed to sort out in my head and which I'm loath to post to the list for fear of holy war. Why do we need a fetch command in the here and now, when ftp appears to provide equivalent functionality? Good question. The best answer I can give is do one thing, and do it well. Adding http functionality to ftp(1) was IMHO wrong. Ftp(1) should concentrate on providing an interactive interface to the FTP protocol, and leave the rest to fetch(1). We need generic FTP and HTTP functionality for a variety of applications (first and foremost, sysinstall and pkg_add(1)), and we need a command-line interface to the FTP and HTTP protocols (fetch(1)). We also need an interactive interface to the FTP protocol (for doing stuff like proxying). These are two very different needs; the fetch(3) library is well suited to the former three applications (sysinstall, pkg_add(1) and fetch(1)) but poorly suited to the latter (ftp(1)). We could of course modify ftp(1) to use libfetch for URL parsing and for HTTP, and its own code for FTP... but I would consider that extremely ugly. Anyway, the patchkit doesn't really add much - it reimplements fetch(1) using the fetch(3) library, so we centralize FTP and HTTP functionality in one single library and avoid duplicating code (and bugs!) all over the place. (for the historically impaired, I originally wrote libfetch at Jordan's request for this exact purpose - it was intended to become the backend for the new installation suite, but I haven't heard from Eugene Skepner in over half a year.) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: fetch(1) / fetch(3) patchkit available
Brian Somers br...@awfulhak.org writes:
What about a non-interactive command for pushing stuff via ftp/http ?
This has always been lacking IMHO (``ftp -n EOF'' is full of
gotchas).
I haven't actually looked at libfetch, but I would think that the
functionality should be there.
Libfetch supports FTP uploads (no HTTP uploads yet, I'm afraid, but
it's on the todo-list). It should be trivial to write a small app
which uploads stdin to a specified URL. The following should work
(modulo error checking):
#include stdio.h
#include fetch.h
int
main(int argc, char *argv[])
{
FILE *f;
int c;
f = fetchPutURL(argv[1], NULL);
while ((c = fgetc(stdin)) != EOF)
fputc(c, f);
return 0;
}
Needless to say, this works with file: URLs as well.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Dennis den...@etinc.com writes: At 02:58 PM 5/28/99 +0200, you wrote: I need to hack the driver file if_xl.c to do the following : Note that this card/driver seems to have serious problems under heavy load. Just so you know. What FreeBSD version do you run? There were a few commits to the xl driver shortly before 3.2 which should have ironed out whatever problems remained. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: symorder for FreeBSD-3.x
Mohit Aron a...@cs.rice.edu writes: its seems that the program symorder only works on coff format object files. Is there an equivalent program in FreeBSD-3.x that works on elf object files ? COFF? FreeBSD never supported COFF, to the best of my knowledge. You might want to take a look at objcopy(1). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: ipfw/natd limitation: controlling access of an unregistered net to the internet
konstantinos.dryllera...@dg21.cec.be writes: I believe the problem that I am facing is common enough, but I have failed to find any extra information except some old postings describing possible changes to natd/ipfw behaviour in the future which do not seem to have taken place. Yes, the problem you're facing is a very common one, and is usually solved by switching to a Real Mail User Agent (tm) which breaks lines at 80 columns or less. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Bill Paul wp...@skynet.ctr.columbia.edu writes: [...] Yes! I like it! Instead of trying to help people, I'll be maddeningly vague! I'll pretend to be helpful but stop short of actually providing any useful information! Then everyone else will go insane instead of me, society will collapse, and I can take over the world while everyone's distracted! Yes, Bill, we love you too :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
